A Quick Guide to Scrum Copyright Paul Klipp 2008
An Explanation of Scrum A classic, and in my opinion flawed, software development approach is to define all functional requirements up front and then deliver an all-inclusive release. Requirements changes can mean additional development, documentation and approval time, thus delaying the entire release. What s more, studies show that many initial requirements prove to be of no value to users and just create additional development and maintenance costs. A contrasting approach is a development methodology known as Scrum. Scrum recognizes the changing nature of requirements and adapts elegantly to them. By delivering working software in small pieces, it allows users to start interacting with the software and to provide valuable feedback that radically improves the quality of the final product. Scrum is actually a rugby term that refers to the heads-down formation of players around the ball. In terms of software development, Scrum falls under the rapid product deployment methodology known as agile development, which also includes Lean Development and Extreme Programming. Scrum breaks requirements into subsets that are the focus of short development iterations which produce deployable, functioning subsets of the overall end result. The first iteration delivers software that the business can use immediately upon deployment. Thus, the business begins to realize ROI relatively quickly and continues to do so incrementally, rather than at the entire project s end. An added benefit occurs in that requirements changes, which tend to occur as the business reviews deliverables, can be made to planned iterations without hindering the iteration currently being delivered. My Experience with Scrum Before discovering scrum, I had spent years managing projects using the standard PMI-based waterfall approach (to be fair, PMI has now embraced agile methods and so PMI and agile are not necessarily mutually-exclusive). I "successfully" managed teams from 2 to 250 people in this manner. I put successfully in quotes, because although I always managed to deliver, I wasn't happy much of the time, nor were the programmers, testers, or clients. It's funny, actually, how we managed to create great software, mostly on time and budget, and yet the process was so often characterized by stress, uncertainty, unproductive meetings, awkward negotiations, late nights in the office, and crisis management. When I started my own software company, I could do things my own way. With new employees and new clients, the only remnant of my past as a project manager was me. I'd read about extreme programming and scrum and I set about to make my future brighter than my past by changing the way I worked. The results were amazing. Five years later, I can say that I've never had a project fail, never missed a deadline, never had an upset client, and only asked my team to work overtime twice to get releases out (I wish I could say it had never happened, but two weekends in five years is still not bad). Scrum made all the difference. For one thing, everyone knows what's happening all the time and shares the same realistic expectation. So even when things go wrong, as they are bound to from time to time in software, everyone including the client knows quickly and works together to solve problems rather than getting frustrated with uncertainty and searching for someone to blame. Frequent, quality communication, short iterations with solid deliverables, and a process that accommodates change elegantly without the need for change orders and renegotiating deadlines and budgets removes all the frustration, stress, and most of the risk from building great software. The Players Scrum Roles Pigs and Chickens Traditional project roles don t exist in the Scrum environment. The team leader, unlike a project manager, does not assign tasks or interact with the business users. The business product owner writes the requirements not someone from the development team. The team as a group shares responsibility for the entire end result, making the individual team member less likely to isolate until finished coding his or her piece of the project. Scrum roles are humorously categorized as either Pigs or Chickens.
Pigs The Pigs are those held accountable for successful, on-time project completion and include the product owner, Scrum team members and the ScrumMaster. ( Their bacon is on the line! ) Chickens The Chickens include stakeholders such as end users and managers who are affected by but are not responsible for the end result. These are all the people interested in the project, whether they are users, marketers, product managers, or financers. They do not play an active role in the scrum process because too many decision-makers (meaning more than one) really introduces a lot of confusion into a process, but they are very welcome to follow the team s progress by listening in on the daily scrum meetings, reviewing the progress via the backlogs and burndown charts, and using the product of each iteration and providing feedback to the Product Owner. Product Owner The product owner represents the users and is responsible for compiling, prioritizing and changing user requirements. In the case of outsourced development, this is usually the client or a representative of the client. Scrum Team A Scrum team contains no more than nine members and consists of hands-on workers such as developers, quality assurance testers and designers. Team members and business users directly interact during the development effort. The fact that they share joint responsibility for the overall project encourages intra-team communication and collaboration. ScrumMaster The ScrumMaster is the Scrum team guide. It is the ScrumMaster s responsibility to remove project impediments and to avoid micro-management. The ScrumMaster also ensures that Scrum practices are followed and that everyone involved is communicating effectively. He or she helps the team to implement best practices and to incorporate into their process the lessons of past experience. The Scrum Process Describing Customer Requirements (User Stories) The customer is responsible for communicating the desired end results. This is done by creating use cases and/or user stories. A user story is a short, one to three sentence description of a desired behavior and may be written by a project manager, an end user, a product owner or another stakeholder. My preferred format for a Sample User Story User Registration Page When a user lands on the registration page, they are prompted to provide their full name, email address, job title, a username, and a password of at least six characters. Submitting this information creates a new user account and generates a confirmation email to the user including login instructions. user story is borrowed from Mike Cohen and it is A user role is able to accomplish some task in order to address some need. The product owner compiles and prioritizes the user stories into a list which is called the product backlog. The product backlog is a living document that is edited constantly as priorities change or new ideas evolve. Creating Iterations (Sprints) The Scrum team, ScrumMaster and product owner meet to break the product backlog into subsets of effort known as iterations or Sprints. An iteration is logically identified based on developer time estimates and product owner prioritization and is further subdivided into detailed tasks collectively known as the Sprint backlog. Each iteration should
be of short duration (e.g. two to four weeks), should deliver functionality that the business can use right away, and should be approved by the product owner. Prior to approving an iteration, the product owner should verify that the user stories for the iteration sufficiently describe what needs to be done. Once approved, an iteration is timeboxed, which means that its user stories and duration are fixed in stone and the iteration will produce tested, deployment-ready software on time, every time. The Iteration/Sprint Process Task Selection Scrum team members select the individual tasks on which they want to work, based on the priority given to the story by the product owner. Highest business value stories are done first. Collaboration Frequent communication among the developers is encouraged and helps to generate a better end result. Ongoing direct interaction between developers and end users minimizes surprises and drastically shortens the feedback loop, increasing efficiency. User Story Testing Right after a user story is completed, it is acceptance tested. Test results are immediately made available to the product owner. Daily Scrum Meetings Throughout the iteration, the ScrumMaster organizes brief (5-15 minute), daily team meetings to share accomplishments and reveal any progress impediments. In the daily scrum, via telephone or Skype, every team member will briefly answer three questions: 1. What have you done since the last scrum? 2. What do you intend to do before the next scrum? 3. What do you need to do your job as effectively as possible? After the scrum meeting, it is the ScrumMaster's job to work with the product owner to remove any impediments to optimal team performance, which could include such things as getting feedback on a new feature, an answer to a question, or obtaining some hardware or software that will improve a team member's performance. Sprint Evaluation The Scrum team may meet with the ScrumMaster and product owner to demonstrate the deliverable at the end of each iteration. Additionally or alternatively, the product owner and business users may evaluate the deliverable outside of the Scrum team s presence. It is up to the product owner to declare when the business value realized by an iteration is sufficient to merit deployment. The product owner is responsible for updating the product backlog and is free to alter subsequent Sprint requirements. Sprint Review/Retrospective At the end of an iteration (Sprint), the Scrum team meets to discuss lessons learned and makes concrete changes to ensure that future sprints are even more effective. This process of continual, gradual improvement is a sustainable way to achieve spectacular results over time.
Modify and Repeat The process of defining, approving, implementing and deploying each iteration is repeated until the product backlog has been completed or the product owner decides that enough business value has been delivered to declare the project a success. In my experience, it is not at all uncommon for a product owner to declare success with 20-30% of the initial backlog items still remaining. These are the items that a tradition development process would include, but which through an iterative and adaptive process, the business owner and end users realize are not really as valuable as they thought at the beginning. The result is higher-quality, lower-cost software delivered faster. Glossary Agile Software Development set of software development methodologies including Lean Development, Extreme Programming and Scrum, designed for rapid deployment and change accommodation Iteration Subset of the software development effort producing a deliverable that can be deployed and used by the business (also known as a Sprint) Product Backlog a high-level list of user stories ( and/or use cases) explaining the functionality that the users require Product Owner a business unit representative who compiles, maintains and prioritizes user requirements for a given product development effort Scrum an agile development methodology for project definition and execution ScrumMaster the person responsible for ensuring that scrum practices are being followed and for working with the product owner to remove any impediments to optimal team effectiveness. Scrum Team a team with no more than nine members directly involved in a given product development effort Sprint Subset of the software development effort producing a deliverable that can be deployed and used by the business (also known as iteration) Sprint Backlog the set of detailed tasks that comprise a Sprint Daily Scrum A daily meeting, timeboxed to fifteen minutes, in which every member of the scrum team appraises the others of their progress and needs by answering the three scrum questions. Any discussion is tabled for after the scrum meeting. Increment A piece of deployable code that is produced at the end of iteration. It represents real business value in the form of completed and fully tested and approved features. Self-managing Team refers to a team that takes responsibility for the quality and completeness of their work and than chooses the route to success that works best for them, as opposed to a "team" of individuals each only interested in their own assigned tasks. A self-managing team is more motivated, generally happier, and more efficient. Story Points A relative unit of measure of the complexity of a user story or task. A team assigns story points to user stories during the planning game and these points are mapped to time based on the team's historic velocity. Velocity - a measure of the average number of story points completed per iteration over time, using a burndown chart. Burndown chart - A line graph with time on the X axis and story points remaining on the Y axis. Displayed boldly on the team's wall, it clearly communicates at a glance the status of the iteration Ideal Days Sometimes a team will estimate tasks in ideal days, which is defined as a solid day's work with no distractions or interference. These don't really exist, but real days can be calculated based on the team's velocity. Retrospective A meeting held at the end of every iteration in which the Scrum team identifies what went well and poorly during an iteration and chooses practices to continue or to modify to make future iterations more successful User Story A short statement that describes a feature in terms of what a user is able to accomplish with the software Use Case A more structured description of a feature that also includes how the software will respond to
different success and failure situations Planning Game The meeting in which the entire scrum team reviews all of the stories for the sprint backlog, identifies tasks, clarifies initial details with the Product Owner, and estimates the stories Themes A group of related stories. Examples of themes might be "user management" and "payment processing". Themes are a good way to organize stories, especially during the initial release planning Roles these define the users of the application. They may be as simple as "registered user" and "system administrator" but I often like more descriptive roles, such as "blog owner", "blog contributor", "blog visitor", "blog commentator" which better define how a user is using the software. Timeboxed - means that a set duration is non-negotiable. A timeboxed meeting might last only 15 minutes, not a second more, and so all participants are motivated to maximize efficiency. A timeboxed iteration means that when the deadline is reached, there will be no excuses. Code must be finished, checked in, tested, approved, and ready to deploy live. Timeboxed iterations make planning easier for stakeholders because they know the promises they make to users will be kept. Need Help? I have helped teams around the world improve their performance through agile methodologies. Whether you need advice, training, or coaching, I can get your team on the road to success with Scrum. I am also available to speak on a variety of topics related to software creation and off shoring. Website: www.paulklipp.com Email: paul@paulklipp.com Skype: paulklipp Further Reading Lean Software Development by Mary Poppendieck and Tom Poppendieck Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen
http://creativecommons.org/licenses/by-nc-sa/3.0/ You are free: to Share to copy, distribute and transmit the work to Remix to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Noncommercial. You may not use this work for commercial purposes. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page. Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights.
Disclaimer