Scrum Puzzle #5
Forgive me Scrum Puzzlers for taking so long to post a new puzzle. I’ve been busy with a side project which will very soon become a lot more than a side project. In exactly 2 weeks I will be self employed! I have started Growing Agile with my good friend and fellow agile enthusiast Sam Laing. We are looking forward to a whole new adventure next year, which I imagine will inspire quite a few Scrum puzzles. Anyway onto my solution to puzzle #4:
My first instinct is to ask what problem you are trying to solve. I personally don’t like estimating tasks at all, but that stems mostly from having seen those estimates abused. Usually I let the team decide what they want to do. I even had a team once that drew a gantt chart on the white board before they would commit. In the example, it seems that the issue is more about developers not being able to collaborate on tasks because they can’t communicate their progress effectively and about not being sure if they will meet the sprint goal or not. Given the resistance from the team towards estimating in hours, I would not push that point. I’d ask them to come up with other ways to tell if they are on track for the sprint, and to be able to collaborate more.
An idea for telling if they are on track. Ask each team member in the standup how confident they are they will meet the sprint goal. 100%, 90% etc. Track this each day. If it starts to drop you have an indication that something is wrong. I think this can be as effective as a burndown. Another alternative if you really want a burn down is simply to count the number of tasks still to be done on the board rather than adding up estimates. It will also give you a trend. Both are these are just some ideas to help you see there is not just one way to solve the problem. The real trick is to figure out what problem you are trying to solve, if it needs solving, and then to engage the team to solve it themselves, rather than trying to solve it for them.
Another technique you might find useful is to decompose tasks as you work, so anytime a task is in progress for more than one day ask the team member: what did you finish yesterday (that can be a task in done), what are you busy with today (that can be in progress), and what won’t you get to today (that can be in to do) and someone else can pick it up. If they struggle with this level of decomposition, then it is probably a warning sign of something else, like maybe a trust issue preventing transparency. Having said that I have to agree with some of the comments that the focus shouldn’t really be on tasks. Take a look at my previous post on breaking down stories to see if you can get smaller stories. A goal I like to set for the team is a cycle time of 2 days per story. i.e. can they go from starting to completing a story in 2 days. If you can get this right, you can burn down story points and you will stop worrying about tasks 🙂
On to Scrum Puzzle #5. You track the team’s velocity over time, to help the Product Owner plan releases. After 6 sprints on the current release the Product Owner comes to because he has noticed that the team’s velocity is dropping each sprint. 6 sprints ago it was 50 points per sprint, and now it is only 30. He is concerned that if the trend continues the team will soon be delivering nothing at all. He wants you as the Scrum Master to talk to the team because he needs the velocity back at 50 if you are to meet the release commitments he has made to the stakeholders. What do you do… (or should that be what did you do, because I know this happens out there!)