Agile Software Project Management With Scrum
Agile Software Project Management with ScrumViljan Mahnic, Slavko DrnovscekUniversity of Ljubljana, Faculty of Computer and Information ScienceTrzaska 25, SI-1000 Ljubljana, Sloveniaviljan.mahnic@fri.uni-lj.si, slavko.drnovscek@fri.uni-lj.siAbstractThe aim of our paper is to describe the experience we haveusing Scrum for agile software project management in auniversity environment. The paper is divided into threeparts. In the first part an overview of the Scrum method isgiven. In the second part we describe how we used Scrumduring the development of (a part of) the student recordsinformation system at the University of Ljubljana. Finally,the advantages of Scrum are summarized.Keywords: agile methods, Scrum, software development1 IntroductionUniversities in Slovenia, like most universities in Centraland Eastern European countries, usually develop their ownsoftware for university information systems. This isespecially true for student records information systemswhich are often so specific that there are no commerciallyavailable solutions in the marketplace. The University ofLjubljana is no exception. In autumn 2001 a project waslaunched with the aim of building a comprehensive webbased student records information system which enablesremote access to data to all parties involved (viz. students,teachers, and administrative staff) [1, 2]. In the beginning,it was a pilot project of three departments, but aftersuccessful completion of the first phase, the project hasbeen extended in order to serve other departments as well.At the moment of this writing the new student recordsinformation system is in use in 15 departments.1Developing software for such a project requires asystematic and manageable software process. During theaforementioned project, we were using an adapted versionof SSADM [3] for analysis and design, and Gantt chartsfor project planning. However, it often happened that theactivities were late and some rework had to be done, partlydue to changes in requirements and partly due to the factthat developers were not familiar with the development of1The university of Ljubljana has a peculiar organizationalstructure, permitting all departments a high level ofautonomy. Consequently, each department maintains itsown student records information system.web based information systems and the new tools they hadto use (viz. Oracle Portal).In order to make software development visible andadaptable we were looking for an agile approach to projectmanagement and decided to try Scrum [4, 5]. We first usedScrum to manage the development of the so calledmaintenance module that upgrades the aforementionedstudent records information system with facilities for themaintenance of data, administration of users, export ofdata to the data warehouse, import of data on freshmenstudents, etc.The aim of this paper is to describe our experience usingScrum on this project. In the next section an overview ofScrum is given. In Section 3 we describe how we usedScrum during the development of the maintenance moduleand present some examples of Scrum artifacts, viz. asample Product Backlog and Sprint Backlog. In Section 4we summarize our experience with the use of Scrum.2 Overview of ScrumScrum belongs to the family of agile softwaredevelopment methods that have attracted significantattention among software practitioners during last fiveyears. Whereas the Extreme Programming method [6] thathas been widely accepted as one of the most importantagile approaches has a definite programming flavour (pairprogramming, coding standards, test driven development,refactoring, continuous integration), Scrum concentrateson managing software projects.Scrum starts with the premise that software development istoo complex and unpredictable to be planned exactly inadvance. Instead, empirical process control must beapplied to ensure visibility, inspection, and adaptation. Thedifferent environmental and technical variables (such ntation technologies and tools, and evendevelopment methods) must be controlled constantly inorder to be able to adapt to changes flexibly. This isachieved through an iterative and incrementaldevelopment process.
Scrum's skeleton is shown in Figure 1.2 The lower circlerepresents an iteration of development activities that occurone after another. The output of each iteration is anincrement of the product. The upper circle represents thedaily inspection that occurs during the iteration, in whichthe individual team members meet to inspect each others'activities and make appropriate adaptations. Driving theiteration is a list of requirements. This cycle repeats untilthe project is completed.requirements that are currently known. The ProductBacklog is prioritized and divided into proposed releases.All work is done in Sprints. Each Sprint is an iteration of30 consecutive calendar days. Each Sprint is initiated witha Sprint planning meeting, where the Product Owner andTeam get together to collaborate about what will be donefor the next Sprint. Selecting from the highest priorityProduct Backlog, the Product Owner tells the Team whatis desired, and the Team tells the Product Owner howmuch of what is desired it believes it can turn intofunctionality over the next Sprint.After deciding what has to be done in the next Sprint, theTeam develops the Sprint Backlog, i.e., a list of tasks thatmust be performed to deliver a completed increment ofpotentially shippable product functionality by the end ofthe Sprint. The tasks in the list emerge as the Sprintevolves and should be divided so that each takes roughly 4to 16 hours to finish.Figure 1 : Scrum skeletonScrum implements this iterative, incremental skeletonthrough three roles: the Product Owner, the Team, and theScrumMaster. The Product Owner is responsible for representing theinterests of everyone with a stake in the project and itsresulting system. He maintains the Product Backlog,i.e., a prioritized list of project requirements withestimated times to turn them into completed productfunctionality.The Team is responsible for developing functionality.Teams are self-managing, self-organizing, and crossfunctional, and they are responsible for figuring outhow to turn Product Backlog into an increment offunctionality within an iteration and managing theirown work to do so. Team members are collectivelyresponsible for the success of each iteration and of theproject as a whole.The ScrumMaster fills the position normally occupied bythe project manager, but his role is slightly different.While the traditional project manager is responsible fordefining and managing the work, the ScrumMaster isresponsible for managing the Scrum process, i.e., forteaching Scrum to everyone involved in the project, forimplementing Scrum so that it fits within an organization'sculture and still delivers the expected benefits, and forensuring that everyone follows Scrum rules and practices.Detailed Scrum flow is shown in Figure 2. A Scrumproject starts with a vision of the system to be developed.Then a Product Backlog list is created containing all the2Figures 1 and 2 are taken form [5].Every day the Team gets together for a 15-minute meetingcalled a Daily Scrum. At the Daily Scrum, each Teammember answers three questions: What have you done onthis project since the last Daily Scrum Meeting? What willyou do before the next meeting? Do you have anyobstacles? The purpose of the meeting is to synchronizethe work of all team members and to schedule anymeetings that the Team needs to forward its progress.Figure 2 : Detailed Scrum flowAt the end of the Sprint, a Sprint review meeting is held atwhich the Team presents what was developed during theSprint to the Product Owner and any other stakeholderswho want to attend. After the Sprint review and prior tothe next Sprint planning meeting, the ScrumMaster alsoholds a Sprint retrospective meeting in order to encouragethe Team to revise, within the Scrum process framework,its development process to make it more effective andenjoyable for the next Sprint.
Together, the Sprint planning meeting, the Daily Scrum,the Sprint review, and the Sprint retrospective constitutethe empirical inspection and adaptation practices ofScrum.Team, and one who performed the roles of Product Ownerand ScrumMaster. The roles of Product Owner andScrumMaster are usually filled by two different persons,but in our specific situation the project was managed bythe Head of Software Engineering Laboratory (viz.ScrumMaster) who was at the same time the Vice-Deanfor Educational Affairs, thus representing also the interestsof project stakeholders (viz. Product Owner).3 Scrum at the University of LjubljanaAt the University of Ljubljana we started using Scrumwithin the project of building the so called maintenancemodule that enables the maintenance of all data requiredfor the proper functioning of the student recordsinformation system, e.g., the maintenance of various codetables, installation parameters, lists of compulsory andoptional courses for each study program, data aboutteachers of each course, etc. Additionally, the maintenancemodule provides facilities for administration of users andtheir rights, export of data to the data warehouse, import ofdata about newcomers, etc.After defining the initial Product Backlog and prioritizingrequirements, it was estimated that the development of therequired software will take three months. Therefore, threeSprints were planned as shown in Table 1.The first four columns represent the Product Backlog itemname, the initial estimate, the complexity factor, and theadjusted estimate. The complexity factor increases theestimate due to project characteristics that reduce theproductivity of the Team. Initially, all Sprints wereplanned to take 20 working days; however, experience hadshown that the adjusted estimate should be taken intoaccount from the very beginning.There were 4 people involved in the development of themaintenance module: three of them as members of theTable 1 : Product backlog at the beginning of the second SprintInitialBacklog eWork ing a new user role41.24.84.800Maintenance of simple code tables81.5121200Maintenance of complex code tables81.5121200Sprint 12028.828.800Maintenance of complex code tables51.15.55.55.5Maintenance of curriculum data71.28.48.48.40Maintenance of teacher's database81.29.69.69.60Sprint 22023.523.523.50Maintenance of installation parameters31.23.63.63.63.6Adding and removing users31.13.33.33.33.3Data import and export51.26666Maintenance of data about degreepending students21.22.42.42.42.4Integration rint 32024242424Release 16076.376.347.524
The Product Backlog evolved as the project evolved.Table 1 represents the situation at the beginning of thesecond Sprint. The rows correspond to the ProductBacklog items, separated by Sprint and Releasesubheadings, and (within each Sprint) ordered accordingto their priority. All of the rows above Sprint 1 representtasks that were worked on in that Sprint. The rowMaintenance of Complex Code Tables is duplicated inSprint 2 because it was only partly completed in Sprint 1,so it was moved down to the Sprint 2 for completion. Thelast three columns represent the Sprint during which theProduct Backlog was developed.After the Product Owner and the Team had agreed aboutthe amount of work to be completed during each Sprint theTeam was left alone to accomplish its tasks. Teammembers maintained the Sprint Backlog and participatedregularly in the Daily Scrum meetings. Table 2 shows theSprint Backlog of our project after the ninth day of thesecond Sprint. The rows represent Sprint Backlog tasks;the columns on the right represent the first 9 days of theSprint. In each column, the estimated number of hoursremaining to complete the task is shown for each task. If atask emerges later in the Sprint it is simply added togetherwith the corresponding estimation (see task Export todifferent schemata). Obviously, in that case the totalnumber of hours of work remaining may increasecompared to the value of the previous day.Table 2: Sprint Backlog after the ninth day of the second SprintTask DescriptionResponsibleStatus (NotStarted/InProgress/Completed)Hours of work remaining123456789Create SIFRANT DATA tableMarkoCompleted200000000Relocate icons for deletion and updateMarkoCompleted300000000Relocate search and insert linksMarkoCompleted100000000Develop toUpper function forSlovenian character setMarkoCompleted330000000Improve diagnostic messagesMarkoCompleted880000000Use default sort orderSlavkoCompleted200000000Include icons for Adapt sorting to Slovenian charactersetMarkoCompleted333000000Refactor sorting functionSlavkoCompleted888888000Keep the selection unchanged ifediting of a record is suspendedSlavkoCompleted222222220Reset of sorting is not necessarySlavkoCompleted222222220Don’t show the search criterionSlavkoCompleted222222220Refactor menu callsMarkoCompleted444000000Complete users manualMarkoCompleted444444400Export to different schemataMarkoCompleted610Maintenance of complex code tables4537261919191770Print out curricula – selection criteriaIgorCompleted1065000000Print out curricula – htmlIgorIn Progress1616161682222Print out curricula – pdf, csvIgorIn Progress1010101010101077
Copy STANJE table – previous yearIgorNot Started666666666Edit STANJE tableSlavkoCompleted999999940Create a list of courses for the nextyear based on data of previous yearMarkoNot Started121212121212121212Add a course in the curriculumIgorNot Started242424242424242424Delete a course from the curriculumIgorNot Started666666666Change course attributesIgorNot Started888888888Add a partial examMarkoIn Progress16161616161616168Delete a partial examMarkoNot Started444444444Change partial exam attributesMarkoNot Started666666666Maintain exam prerequisitesMarkoNot 912121212121212126Maintenance of curriculum dataPrint out all data for a specified yearSlavkoIn ProgressCopy the last year settingsSlavkoDisregardedAdd a new teacherSlavkoNot Started161616161616161616Delete a teacher for a specified yearSlavkoNot Started161616161616161616Change examination dates because ofteacher changesSlavkoNot ance of teacher's databaseThere were no other elaborate plans during a Sprint, butthe Team members were expected to be guided by theirknowledge and experience on the basis of selforganization. Daily meetings allowed everyone on theproject team to see the status of all aspects of the project inreal time. The Sprint goals were an effective tool forkeeping the Team on track and aware of expectations. Wenoticed an increase in volunteerism within the Team. Theywere taking an interest in each other's tasks and were moreready to help each other out. The best part of Scrummeetings was the problem resolution and clearing ofobstacles. The meetings let the Team take advantage of thegroup's experience and ideas.The ScrumMaster acted merely as a coach or mentor. Hismain task was to fend off changes during a Sprint toprotect the Team from getting sidetracked. Nobody wasallowed to change the Sprint goals. At the end of eachsprint a Sprint review meeting took place at which theTeam demonstrated the shippable increment of productfunctionality.Each Sprint (except the first) produced tested andshippable code. During the first Sprint programs formaintaining code tables were developed that needed someelaborations (mainly regarding the user interface)requested by users at the Sprint review meeting. Users'remarks were considered in the second Sprint. After thesecond Sprint programs for maintenance of curriculumdata and teacher's database were completed. Project wasfinished in time after the completion of the third Sprint.4 ConclusionsThe Team members found Scrum very useful. The use ofScrum improved the communication among them andmaximized co-operation. It also increased their motivationand responsibility for the success of the project. On theother hand, it gave them freedom to maximally exploittheir talent and knowledge during each Sprint. They wereable to organize their work by themselves consideringtheir preferences and special knowledge. At the end of theproject they felt good about their job, their contributions,and they believed that they had done the very best theypossibly could.From the Product Owner's and ScrumMaster's point ofview it was most important that the software developmentprocess became visible, controllable, and manageable. Allimpediments were immediately detected during DailyScrum meetings and removed as soon as possible. It wasalso important that each Sprint produced a shippableincrement of functionality that could be put into operationimmediately.
Our experience corresponds to findings reported in theliterature [7, 8]. As a result of the use of Scrum: the product becomes a series of manageable chunks, progress is made, even when requirements are notstable, everything is visible to everyone, team communication improves, the Team shares successes along the way and at theend, customers see on-time delivery of increments, customers obtain frequent feedback on how theproduct actually works, a relationship with the customer develops, trust builds,and knowledge grows, and a culture is created where everyone expects the projectto succeed.References[1] Mahnic, V., Bajec, M. Introducing e-businesstechnology in the area of student records,Proceedings of the 8th International Conference ofEuropean University Information Systems EUNIS2002, Porto, Portugal, 19-22 June 2002, pp. 300-304.[2] Mahnic, V., Bajec, M. Reengineering of the studentrecords information system, Proceedings ofInternational Conference on University InformationSystems UNINFOS 2003, Nitra, Slovakia, 3-5September 2003, pp. 212-218.[3] Goodland, M., Slater, C. SSADM, A PracticalApproach, McGraw-Hill, 1995.[4] Schwaber, K. and Beedle, M. Agile SoftwareDevelopment with Scrum, Prentice Hall, 2002.[5] Schwaber, K. Agile Project Management with Scrum,Microsoft Press, 2004.[6] Beck, K. Extreme Programming Explained, AddisonWesley, 2000.[7] Rising, L., Janoff, N. S. The Scrum SoftwareDevelopment Process for Small Teams, IEEESoftware, July/August 2000.[8] Sutherland, J. Agile Development: Lessons therland.com/scrum/FirstScrum2004.pdf,page visited on 21.2.2005.
using Scrum for agile software project management in a university environment. The paper is divided into three parts. In the first part an overview of the Scrum method is given. In the second part .
1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18
Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .
Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.
1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.
1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma
The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .
AGILE TESTING For agile testers, test engineers, test managers, developers, technical leads. Ensure the production of effective and valuable software. Agile Fundamentals Agile Programming Agile Software Design Agile Fundamentals Agile Testing Agile Test Automation ICP CERTIFIED PROFESSIONAL ICP CERTIFIED PROFESSIONAL ICP-PRG CERTIFIED .
The Agile Customer. 9/4/2013 6 Agile Development Team Agile Analyst. 9/4/2013 7 Agile Programmer Agile Tester. 9/4/2013 8 Agile Manager Agile Usability Designer. 9/4/2013 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any software
