(Anders dan de rest van de website content zijn de retrospectives in het Engels, omdat ze ook gepubliceerd zijn als Pulse op LinkedIn)
How break-downs can be used to make estimations and planning more accurate
Planning poker is fun. Using relative story points is by far the best way to estimate the amount of time a task will take. And estimates are needed at the beginning of each sprint so the team can fill the backlog and get an insight in their upcoming velocity. Right?
Nope! Well, it’s only partly right. Scrum is an empirical process. Estimating time can be in conflict with this. Scrum is unpredictable in its nature and performing estimations can create a false sense of control. In the words of Esther Derby: “Estimating is helpful, estimates are often not”. So, yes, keep estimating. As long as estimations do not endanger the empirical nature of agility. Keep in mind that doing the estimation in your scrum team and discussing differences is more important than the actual numeric outcome.
Slicing the cake
In scrum, user stories are first sliced into manageable portions and than dragged into the sprint backlog where they are divided into smaller pieces of action (work items, tasks). An unwritten rule in scrum is that these items should take about two to four hours to complete, at a maximum of two days. A lot of teams however only ‘poker’ the total time for the story, not for the individual work items. And a lot of times the amount of work estimated exceeds the two days limit. These teams struggle with good break-downs and thus come up with unrealistic estimations that endanger completion of the sprint goal.
That said, if a team – and this would be surely the case with a team relatively new to scrum – wants to estimate the amount of work a story or task will take, they should better get it right. There are various ways to do so, but I opt for the so called break-down into Deliverables and Activities. To show why is like this way of working, I have thought out a simple retrospective and called it ‘Divide and Conquer’.
- Whiteboard and markers
- Calculator (for verification)
- Stopwatch / timer
- Make sure the WHOLE scrum team is present
Step 1: Calculation by head*
- Write a multiplication sum on the board. For example 1234 x 5678 = …..
- The team estimates the time it will take to solve the calculation in minutes and seconds
- (If needed they can use planning poker or hand voting to get consensus)
- Now let the best mathematician in the team solve the sum on the board
- Use a stopwatch to keep track of the amount of time he or she needs to solve it
- Calculate the percentile difference between the estimated time and the real time (this might actually come close)
Step 2: Make a break-down
- Write the same sum on a freshly clean on the whiteboard.
- Break up the sum in parts. Depending on the method used, this might result in:
A: Multiply the first bottom number with all numbers above (8×4 + 8×30 + 8×200 + 8×1000)
B: Add up the four results (32 + 240 + 1600 + 8000)
C: Repeat step A + B for the other (3) bottom numbers
D: Add up the four results of step C = outcome
- It can be handy to use a flip-over or even make a mind map for this.
Step 3: Estimate the time based on the break-down
- Calculate the time per step and add up the totals.
- In this case: ((A + B) x 4) + D
- You can let team members all solve a part of the sum. So work as a team and divide the work. A side effect can be (as I have seen) that team members all focus on their own piece of work and forget to focus on the whole task (ergo: do not add up the totals).
Step 4: Objections, your honour
- ‘This takes too much time. A lot more than the actual execution!’
- ‘Hell yes, but that’s only with easy tasks. So try this one: 12345678 x 12345678 = calculation time in minutes.’
Step 5: Write the sum in a user story
- Let the team translate the calculation into a user story (As … I want … So that ….).
- Divide the story into a Deliverable (the resolved sum) and the needed Activities (steps A – D).
- If necessary, do some more exercise with break-downs.
Step 6: Evaluate
Because being agile is all about insights of your team members, as a scrum master you should be able to give the team the time to obtain these insights. Most often you already know where you want to go and what ideas you’d like to pop up. And still you must be patient. On top of that you have to live with the knowledge that insights don’t necessarily mean change of behaviour. Being a scrum master can be hard at times 🙁
So, ask the team which benefits they deduct from estimating with break-downs. They might come up with things you didn’t. But to help you, I’ll write down some benefits I myself see. Next to being able to make better estimations, there are some other positive aspects of using break-downs.
- First of all, break-downs result in smaller tasks and thus better transferability (the tasks can be retrieved by other team members when, for example the one who started working on it is sick).
- Another benefit is that the team will better recognize patterns in future complex tasks and will be able to reproduce a break-down, even by head.
- Also one to take into account: smaller tasks are easier reviewed and checked by other team members.
- Another one: smaller tasks pave the road to early release. Cut work into pieces, built the product, release it to the customer and get the Inspect & Adapt wheel spinning!
- Last but surely not least: the more tasks you break a story into, the more items can be dragged to DONE. Or as lean puts it: ‘Stop starting, start finishing’. And finishing tasksof course is always a good feeling.
Scrum you later!
* Since there are various ways to solve a multiplication sum (like this amazing Japanese one), you might want to choose one method up front. And, if needed, it could also be wise tot brush up your own calculation skills.