SCRUM AND XP FROM THE TRENCHES, by Henrik Kniberg
How we do product backlogs
The product backlog is the heart of Scrum. The product backlog is a prioritised list of all user stories/features that the customer wants. They are called stories, or just backlog items. You write them down onto cardboard squares and post them up onto the Product Backlog whiteboard.
Each backlog item cardboard square should contain the following fields:
ID - a unique identification, just an auto-incremented number. This is to avoid losing track of stories if they are renamed.
Name - a short, descriptive name of the story.
Importance - with a higher number indicating a higher priority.
Initial estimate - in story points, which roughly correspond to 'ideal man-days' (i.e. if three guys locked into a room for four days undisturbed can complete the story, it's a 12-point story).
How to demo - a high-level description of how this story will be demonstrated on the sprint demo day.
Notes - any other info or clarification.
Maintain the product backlog also in Excel format, with sharing enabled.
How we prepare for the sprint planning
Important lesson: Make sure the product backlog is in shipshape before the sprint planning meeting. This means:
There should be one product backlog and one product owner (per product).
All important items should have different importance ratings assigned.
The product owner should understand each story.
How we do sprint planning
The spring planning meeting is critical, because a badly executed sprint planning meeting can mess up a whole sprint.
The output of the sprint planning meeting is:
A sprint goal.
A list of team members (and their commitment levels, if not 100%).
A sprint backlog (=list of stories included in the sprint).
A defined sprint demo date.
A defined time and place for the daily scrum.
The product owner must attend the sprint planning, even if it takes hours. This is because each story contains three variables that are dependent on each other:
Scope - set by the product owner.
Estimate - set by the team.
Importance - set by the product owner.
During the sprint planning, these variables are fine-tuned through face-to-face dialogue between the team and the product owner.
A fourth variable, quality, is not negotiable and is not up for discussion. There are two types of quality:
External quality - what is perceived by the users of the system.
Internal quality - design consistency, test coverage, code readability, refactoring, etc.
External quality is part of Scope. Internal quality is not negotiable. Don't let the product owner or the team try to use quality as a variable in negotiations.
Don't let the sprint planning meeting drag on, because people get tired and it doesn't accomplish anything. Time-box the sprint planning meeting from the outset.
The agenda of the meeting has four parts:
Product owner goes through the sprint goal, summarises the product backlog. Demo date is set.
Team time-estimates each user story.
Team selects stories to be included in the sprint.
Select time and place for daily scrum. Further breakdown of stories into tasks.
The best length for a sprint is three weeks. It's short enough to give adequate corporate agility, and long enough for the team to achieve flow.
Make sure you define the sprint goal. It should answer the fundamental question, "Why are we doing this sprint? Why don't we all just go on vacation instead?" The goal should be in business terms, not technical terms.
The team decides which stories to include in the sprint, not the product owner. To determine which stories can make it into the sprint, the team estimates its velocity:
Velocity = [available man-days] x [focus factor]
For example, for a three-week sprint (15 work days), 4-person team, with Lisa on vacation for two days, and Dave only available 50% of the time:
Total available man-days = 50
However, in practice there are disturbances and distractions. The focus factor is a percentage that reflects these disturbances. The best way to determine a reasonable focus factor is to look at the last sprint (or last few sprints).
For example if the focus factor is 60%, then velocity = 50 x 60% = 30 story points.
The "default" focus factor to use for new teams is usually 70%, since that is where most teams typically end up over time. It is recommended that you plan your sprints to have a velocity of 40-60.
Although the product backlog is kept in Excel, for the purposes of the sprint planning meeting, the stories should be written onto index cards and put onto the whiteboard. This is better than using a projector to project the Excel sheet because:
People stand up and walk around (=> stay awake and alert longer)
Everybody feels more personally involved (rather than just the guy with the keyboard)
Re-prioritising is trivial - just move the index cards around.
After the sprint planning meeting, the scrum master should manually update the Excel-based product backlog with respect to any changes that were made with the physical index cards.
Time-estimates are easier to do if each story is broken down into tasks. Add little post-it notes under each story to represent the tasks. There is no need, however, to update the Excel-based product backlog with respect to task breakdowns, because the task breakdown is usually quite volatile, and the product owner doesn't need to get involved at this level of detail anyway.
Definition of Done
The product owner and team should agree on a clear Definition of Done. Is a story complete when all code is checked in? Or is it complete only when it has been deployed to a test environment and tested? The best DoD is "ready to deploy to production".
If you ask the team to provide a story estimate, normally the person who understands the story best will be the first one to blurt one out. Unfortunately, this will strongly affect everybody else's estimates.
Use planning poker. Each team member gets a deck of 13 cards (numbered 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, '?', 'coffee'). 0 means "this story is pretty much nothing, just a few minutes work". '?' means "I have no idea". 'coffee' means "I'm too tired to think, let's take a short break".
When estimating a story, each team member puts a card face-down on the table corresponding to his estimate. Then all the cards are revealed simultaneously.
If there are large discrepancies between estimates, the team discusses the differences and breaks down the story into more tasks to get a better estimate.
How to demo
For each story, discuss how to demo. This will ensure that the product owner's understanding of a story matches the team's understanding, and that there won't be a nasty surprise at the end of the sprint.
Breaking down the stories
Stories shouldn't be too small or too big. If you have a bunch of 0.5-point stories you are probably a victim of micro-management. On the other hand, a 40-point story has a good chance of ending up partially complete. Break large stories into smaller ones. Strive for 2-8 man-day stories. If your team velocity is 40-60, that gives around 10 stories per sprint. That's a manageable number of index cards to deal with.
Breaking stories into tasks
Breaking stories into tasks often reveals additional work that needs doing, causing time estimates to go up. It hence gives a more realistic sprint plan.
It is highly recommended to use Test Driven Development (TDD). The first task is to always "write a failing test" and the last task is "refactor".
Morning scrums are best. Select the earliest time at which nobody in the team groans. E.g. 9h00 or 9h30.
Tech stories are non-functional items, that have no direct value to the product owner. E.g. "Refactor the DAO layer" or "Upgrade Jira".
The product owner is often not a techie and won't understand them. So try to avoid tech stories - look for a way to transform a tech story into a normal story with measurable business value. If that isn't possible, keep a separate list of tech stories and negotiate with the product owner for their inclusion in the sprints.
*Bug tracking system vs product backlog
How do you bring bugs (recorded in your bug tracking system) into the sprint? Obviously, it won't do to just ignore them and only focus on stories. There are three possible solutions:
Product owner prints out the highest priority bugs and makes stories out of them.
Bug-fixing is considered to be outside of the sprint (and the team keeps a low-focus factor to reflect that, e.g. 50%).
Put the product backlog into your bug tracking system - i.e. ditch Excel; treat bugs just like any other story.
How we communicate sprints
Create a Sprint Info Page, e.g.:
| Jackass team, sprint 15
Sprint goal: Beta-ready release!
Sprint backlog: (estimates in parenthesis)
- Deposit (3)
- Migration tool (8)
- Backoffice login (5)
- Backoffice user admin (5)
Estimated velocity: 21
- Sprint period: 6 Nov to 24 Nov.
- Daily Scrum: 9h30am in the team room
- Sprint demo: 24 Nov at 13h00 in the team room
Team: Jim (scrummaster), Erica, Tom (75%), Eva, John
Print the sprint info page and post it on the wall outside of the team room. Email it to all company staff, and post it into the wiki.
How we do sprint backlogs
Use a wall-based taskboard.
At the start of the sprint, everything is in the "Not checked out" column. As days go by, stories that someone has started work on are moved into the "Checked out" column, and then into the "Done" column when they are completed.
The burndown chart has time on the x-axis and the estimated work remaining (story points) on the y-axis. Skip weekends on the x-axis to avoid it looking like the burndown chart "flattens out" on weekends.
How we arrange the team room
This is very important: Seat the team together.
The product owner should not be seated with the team. Why? Because chances are that he will not be able to stop himself from meddling in details, and the team will not "gel" properly.
Keep the managers at bay also. When a manager walks in, the team automatically becomes less self-managing.
If you are a manager, do get involved as closely as possible, but only for a limited period, then get out and let the team gel and self-manage. Check up on the team once in a while (not too often) by attending sprint demos and looking at the taskboard and listening in on morning scrums. If you see an improvement area, take the scrum master aside and coach him, but not in front of the team.
How we do daily scrums
Do the daily scrum at the same time every day, at the same place, on time, and in the team room right in front of the taskboard. Time-box the daily scrum to 15 minutes, and do it standing up (that way it won't drag on).
Each team member answers three questions:
What did I do yesterday?
What will I do today?
What difficulties am I encountering?
The taskboard should be updated during the daily scrum, preferably by each team member in turn as they answer their three questions. This is better than having the scrum master as the sole maintainer of the taskboard.
Dealing with latecomers: have a can of coins/banknotes. When you are late, even if only by one minute, you need to add a fixed amount to the can. The money in the can is used for social events.
How we do sprint demos
The sprint demo is important because:
The team gets credit for their accomplishment. They feel good.
Other people learn what the team is doing.
The demo attracts vital feedback from stakeholders.
Demos are a social event where different teams can interact.
Doing a demo forces the team to actually finish stuff.
Checklist for sprint demos:
Make sure you clearly communicate the sprint goal.
No need to spend time preparing the demo; cut the crap and just focus on demonstrating actual working code.
Keep a high pace; make the demo fast-paced rather than beautiful.
Keep the demo business-oriented; leave out the technical details. Focus on "what we did" rather than "how we did it".
Let the audience try the product themselves.
Mention minor bug fixes and trivial items, but no need to demo them.
How we do sprint retrospectives
Sprint retrospectives are very important because they are the team's best chance to improve. Without retrospectives, you will find that the team keeps making the same mistakes over and over again.
The retrospective should be 1-3 hours, and the product owner should also attend.
Don't do the retrospective in the team room, as people's attention will tend to wander. Choose a cozy sofa corner, rooftop patio, etc.
Scrum master should summarise the sprint and review the taskboard.
Do "the rounds": each person gets a chance to say what they thought was good, what could have been better, and what should be done differently next time.
Compare and discuss estimates vs. actual velocity.
At the end of the retrospective, the scrum master summarises concrete suggestions about what can be done better next sprint.
The underlying theme of the retrospective should be "what can we do better next sprint".
Draw three columns on a whiteboard:
Good - things that went well during the sprint.
Could have done better - things we should have done differently.
Improvements - concrete ideas about how to improve in the future.
Write each items onto Post-It notes and paste them onto the whiteboard. The team then uses "dot-voting" to determine which improvements to focus on during the next sprint: each team member gets three magnets and can place them on the items he would like prioritised during the next sprint. He can even place all three magnets on the same issue.
To spread the lessons learnt between teams, one person should attend all sprint retrospectives and act as the knowledge bridge. Preferably a person of authority in the company.
Typical things that come up during retrospectives are:
"We should have spent more time breaking down stories into tasks."
"Too many external disturbances."
"We overcommitted and only got half of the stuff done."
"Our office environment is too noisy and messy."
Slack time between sprints
Sprints are quite intensive. Have one or two "lab days" between sprints, days where developers can do essentially whatever they want. E.g. read up on the latest tools and APIs, etc.
Combining Scrum and XP
Scrum works well with XP. Scrum focuses on management and organisation practices whereas XP focuses on actual programming practices:
Pair Programming - it improves code quality and team focus and knowledge spread. It is, however, exhausting and should not be done all day. Shift pairs frequently.
Test-Driven Development (TDD) - Amen! TDD is more important than both Scrum and XP.
Incremental design - it is mostly an automatic side effect of doing TDD.
Collective code ownership - arises from pair programming with frequent rotation of pairs.
Informative workspace - make use of available wall space to display information about the product and project. The biggest problem is old junk accumulating on the walls, so introduce a "housekeeper" role in the team.
Sustainable pace / energised work.
How we do testing
Put a tester into the scrum team. The tester is the signoff guy. Nothing is considered "done" in a sprint until he says it's done.
A nice side effect of this is that the team now has a guy who is perfectly suited to organize the sprint demo.
How we handle multiple scrum teams
The optimal team size is 5-9 people. To split a large team into two smaller teams, keep your eyes and ears open and look for signs of "virtual teams" - who is talking to who in the team.
It is better to synchronise the sprints of the various teams (rather than have them overlap). It makes it easier to rearrange teams, leads to better collaboration between teams, and causes less administrative overhead.
Don't create component-specialised teams ("client team", "server team", "DB team"). Cross-component teams are better.
Avoid re-arranging teams unless absolutely necessary. One of the key aspects of scrum is "team gel". If a team gets to work together over multiple sprints, they will usually become very tight. They will learn to achieve group flow and reach an incredible productivity level. But it takes a few sprints to get there. If you keep changing the teams around, you will never achieve really strong team gel.
Having part-time members of a scrum team is generally not a good idea.
The Scrum-of-Scrums is a meeting where all scrum masters gather up to talk. Once a week is a good frequency.