As a brief introduction, Scrum is an agile process for software development. With Scrum, projects progress via a series of iterations called sprints. Each sprint is typically 2-4 weeks long. Scrum is ideally suited for projects with rapidly changing or highly emergent requirements.
Introduction to Terms
A scrum team is typically made up of between five and nine people, but Scrum projects can easily scale into the hundreds। The team does not include any of the traditional software engineering roles such as programmer, designer, tester, or architect। Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that “we’re all in this together.”
The product owner is the project’s key stakeholder and represents users, customers and others in the process। The product owner is often someone from product management or marketing, a key stakeholder or a key user.
The ScrumMaster is responsible for making sure the team is as productive as possible. The ScrumMaster does this by helping the team use the Scrum process, by removing impediments to progress, by protecting the team from outside, and so on.
The product backlog is a prioritized features list containing every desired feature or change to the product.
At the start of each sprint, a sprint planning meeting is held during which the product owner prioritizes the product backlog, and the scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to the sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.
Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the daily scrum.
At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint. Typically, this takes the form of a demonstration of the new features, but in an informal way; for example, PowerPoint slides are not allowed. The meeting must not become a task in itself nor a distraction from the process.
Note
The term “backlog” can get confusing because it’s used for two different things. To clarify: the product backlog is a list of desired features for the product. The sprint backlog is a list of tasks to be completed in a sprint.
A Visual Introduction to Scrum
Graphically, Scrum looks something like this:
This graphic is an introduction to everything essential in Scrum agile software development. On the left, we see the product backlog, which has been prioritized by the product owner and contains everything wanted in the product that’s known at the time. The 2-4 week sprints are shown by the larger green circle.
At the start of each sprint, the team selects some amount of work from the product backlog and commits to completing that work during the sprint. Part of figuring out how much they can commit to is creating the sprint backlog, which is the list of tasks (and an estimate of how long each will take) needed to deliver the selected set of product backlog items to be completed in the sprint.
At the end of each sprint, the team produces a potentially shippable product increment — i.e. working, high-quality software. Each day during the sprint, team members meet to discuss their progress and any impediments to completing the work for that sprint. This is known as the daily scrum, and is shown as the smaller green circle above.
The Daily Scrum Meeting
On each day of a sprint, the team holds daily meetings (“the daily scrum”). Meetings are typically held in the same location and at the same time each day. Ideally the daily scrums are held in the morning as they help set the context for the coming day's work.
There is an old joke in which a chicken and a pig are talking and the chicken says, "Let's start a restaurant." The pig replies, "Good idea, but what should we call it?" "How about 'Ham and Eggs'" says the chicken. "No thanks," says the pig, "I'd be committed, you'd only be involved." The joke is meant to point out the difference between those who are committed on a project and those who are only involved. Scrum affords special status to those who are committed and many teams enforce a rule in which only those who are committed are allowed to talk during the daily scrum.
All team members are required to attend the daily scrum. Since both the ScrumMaster and Product Owner are committed team members, they are expected to attend and participate. Anyone else (for example, a departmental VP, a salesperson, or a developer from another project) is allowed to attend but is there only to listen. This makes the daily scrums an excellent way for a Scrum team to disseminate status information--if you're interested in hearing where things are at, attend that day's meeting.
The daily scrum is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily scrum. During the daily scrum each team member provides answers to the following three questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
Any impediments that are raised become the ScrumMaster's responsibility to resolve as quickly as possible. Typical impediments are:
My ____ broke and I need a new one today.
I still haven't got the software I ordered a month ago.
I need help debugging a problem with ______.
I'm struggling to learn ______ and would like to pair with someone on it.
I can't get the vendor's tech support group to call me back.
Our new contractor can't start because no one is here to sign her contract.
I can't get the ____ group to give me any time and I need to meet with them.
The department VP has asked me to work on something else "for a day or two."
In cases where the ScrumMaster cannot remove these impediments directly himself (e.g., usually the more technical issues) he still takes responsibility for making sure someone on the team does quickly resolve the issue.
Learning Scrum - The Product Backlog
The Product Backlog is the master list of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of easily. This is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.
Product backlog items can be technical tasks ("Refactor the Login class to throw an exception") or more user-centric ("Allow undo on the setup screen"). My preference is to write express the product backlog in the form of user stories, which are a technique borrowed from Extreme Programming, another agile process.
The product owner shows up at the sprint planning meeting with the prioritized product backlog and describes the top items to the team. The team then determines which items they can complete during the coming sprint. The team then moves items from the Product Backlog to the Sprint Backlog. In doing they expand each Product Backlog item into one or more Sprint Backlog tasks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritized Product Backlog list and draws a line after the lowest of the high priority items they feel they can complete. In practice it is not unusual to see a team select, for example, the top five items and then two items from lower on the list but that are associated with the initial five.
An example Product Backlog from a real project appears as the following:
This Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by the Product Owner. Estimates have been developed by the developers but it is understood that they are very imprecise and are useful only for rough assignments of tasks into the various sprints.
Learning Scrum - The Product Owner
The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.
The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog.
In return for their commitment to completing the selected tasks (which, by definition, are the most important to the product owner), the product owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.
Release Burndown Charts for Scrum & agile projects
On a Scrum project, the team tracks its progress against a release plan by updating a release burndown chart at the end of each sprint. The horizontal axis of the release burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers--story points, ideal days, team days, and so on. My preference is for story points, for all of the reasons described in the Agile Estimating and Planning book.
On this burndown chart, the team started a project that was planned to be eleven two-week sprints. They began with 200 story points of work. The first sprint went well and from the chart you can infer that they had around 180 story points of work remaining after the first sprint. During the second sprint, however, the estimated work remaining actually burned up. This could have been because work was added to the project or because the team changed some estimates of the remaining work. From there the project continued well. Progress slowed during sprint 7 but then quickly resumed.
This type of release burndown chart works very well in many situations and in many teams. However, on projects with lots of changing requirements you may want to look at an alternative release burndown chart.
Learning Scrum - The ScrumMaster
The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint.
The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings.
The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone.
Scrum Team Training
Scrum teams do not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."
A typical Scrum team is 5-9 people. Rather than scaling by having a large team, Scrum projects scale through having teams of teams. In this way I have worked on projects with over 500 people and have consulted to projects with over 1,000.
Although not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach each Scrum team proceeds as normal but each team identifies one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.
The illustration below shows how a Scrum of Scrums approach allows Scrum to scale up (in this case to 243 people). Each cell represents one person on a Scrum team. The bottom of this illustration shows teams with nine developers on them. One person from each team (the differently colored cell) also participates in a Scrum of Scrum to coordinate work above that team. Then from those nine-person teams another person is selected (this time shown with diagonal lines) to participate in what is called a Scrum of Scrums of Scrums.
Scrum Training on Sprint Backlog
The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the team's perception of the time it will take to complete the various features.
It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to.
The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile. An example of the Sprint Backlog in Excel looks like this:
During the Sprint the ScrumMaster maintains the sprint backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done. The estimated work remaining in the sprint is calculated daily and graphed, resulting in a sprint burndown chart like this one:
The team does its best to pull the right amount of work into the sprint but sometimes too much or too little work is pulled in during the Sprint planning meeting. In this case the team needs to add or remove tasks. In the above sprint burndown chart you can see that the team had pulled in too much work initially and still had nearly 600 hours to go on 5/16/02. In this case the Product Owner was consulted and it was agreed to remove some work from the sprint, which resulted in the big drop on the chart between 5/16/02 (619 hours) and 5/17/02. From there the team made good consistent progress and finished the sprint successfully.
Agile Training on Sprint Planning Meeting
The Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives.
During the sprint planning meeting the product owner describes the highest priority features to the team. The team asks enough questions during this meeting so that they can go off after the meeting and determine which tasks they will move from the product backlog to the sprint backlog.
The product owner doesn't have to describe every item being tracked on the product backlog. Depending on the size of the backlog and the speed of the team it may be sufficient to describe only the high priority items, saving the discussion of lower priority items for the next sprint planning meeting. Typically, the Scrum team will provide guidance when they start to get further into the backlog list than they know could be done in the next sprint.
Collectively, the Scrum team and the product owner define a sprint goal, which is a short description of what the sprint will attempt to achieve. The success of the sprint will later be assessed during the Sprint Review Meeting against the sprint goal, rather than against each specific item selected from the product backlog.
After the sprint planning meeting, the Scrum team meets separately to discuss what they heard and decide how much they can commit to during the coming sprint. In some cases there will be negotiation with the product owner but it will always be up to the team to determine how much they can commit to completing.
Sprint Review Meeting
At the end of each sprint a sprint review meeting is held. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.
The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.
Participants in the sprint review typically include the Product Owner, the Scrum team, the ScrumMaster, management, customers, and developers from other projects.
Purpose of a Sprint Review
During the sprint review the project is assessed against the sprint goal determined during the Sprint planning meeting. Ideally the team has completed each product backlog item brought into the sprint, but it is more important that they achieve the overall goal of the sprint.
Training for Scrum Task Board Use
We use a task board during Scrum sprints (iterations). The task board shows all the work we’re doing during a sprint. We update it continuously throughout the sprint–if someone thinks of a new task (“Test the snark code on Solaris 8”) she writes a new card and puts it on the wall. Either during or before the daily scrum, estimates are changed (up or down) and cards are moved around the board.
Generically, the task board looks like this:
Each row on the task board is a user story, which is the unit of work I encourage teams to use for their product backlog product backlog. During the sprint planning meeting the team selects the product backlog items they can complete during the coming sprint. Each product backlog item is turned into multiple sprint backlog items. Each of these is represented by one task card that is placed on the task board. Each task card starts on the task board in the “To Do” column. The columns I always use on a task board are:
- Story–The story description (“As a user I want to…”) shown on that row.
- To Do–This holds all the cards that are not done or in process.
- Work In Process–Any card being worked on goes here. The programmer who chooses to work on it moves it over when she’s ready to start the task. Often this happens during the Daily Scrum when someone says, “I’m going to work on the boojum today.”
- To Verify–A lot of tasks have corresponding test task cards. So, if there’s a “Code the boojum class” card there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t often get corresponding test cards (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column.
- Done–Cards pile up over here when they’re done. They’re removed at the end of the sprint. Sometimes I remove some or all during a sprint if there are a lot of cards.
Optionally, I sometimes use the following columns depending on the team, the culture, the project, and other considerations:
- Notes–Just a place to jot a note or two
- Tests Specified–I like to do “Story Test-Driven Development,” which means the tests are written before the story is coded. I’m not a stickler about it but it does help when there’s time to specify the tests (at a high level) in advance. This column just contains a checkmark to indicate the tests are specified. Ideally, not a lot of work (in the form of task cards) crosses this column without a checkmark in it.
Here are some photos of actual task boards in use।
A task board hanging in a team room।
Cork board hung on the wall.
A metal task board with cards placed with magnet.
A task board made with black tape on a large wall-sized cabinet. There's food in the cabinet!
A distributed team using Outlook's notes facility on a shared desktop.
No comments:
Post a Comment