We have been using Scrum for around 9 months and it has largely been successful. However our burndown charts rarely look like the ‘model’ charts, instead resembling more of a terrifying rollercoaster ride with some vomit inducing climbs and drops.
To try and combat this we are spending more time before the sprint prototyping and designing but we still seem to discover much more work during the sprint than initially thought. Note: By this I mean the work required to meet the backlog is more involved than first thought rather than we have identified new items for the backlog.
Is this a common problem with Scrum and does anyone have any tips to help smooth the ride?
I should point out that most of our development work is not greenfield, so we are maintaining functionality in an existing large and complex application. Is scrum less suited to this type of development simply because you don’t know what problems the existing code is going to throw up?
Just how much time should we be spending before the sprint starts working out the detail of the development?
UPDATE: We are having more success and a smoother ride now. This is largely because we have taken a more pessimistic view when estimating which is giving us more breathing space to deal with things when they dont go to plan. You could say its allowing us to be more ‘agile’. We are also trying to change the perception that the burn down chart is some kind of schedule rather than an indication of scope v resources.
Some tips on smoothing things out.
1) As others have said – try and break down the tasks into smaller chunks. The more obvious way of doing this is to try and break down the technical tasks in greater detail. Where possible I’d encourage you to talk to the product owner and see if you can reduce scope or ‘thin’ the story instead. I find the latter more effective. Juggling priorities and estimates is easier if both team and product owner understand what’s being discussed.
My general rule of thumb is any estimate bigger than half an ideal day is probably wrong 🙂
2) Try doing shorter sprints. If you’re doing one month sprints – try two weeks. If you’re doing two weeks – try one.
3) Use the stand ups and retrospectives to look a bit more at the reasons for the ups and downs. Is it when you spend time with particular areas of the code base? Is it caused by folk misunderstanding the product owner? Random emergencies that take development time away from the team? Once you have more of an understanding where ups and downs are coming from you can often address those problems specifically. Again – shorter sprints can help make this more obvious.
4) Believe your history. You probably know this one… but I’ll say it anyway 🙂 If fiddling with that ghastly legacy Foo package took 3 x longer than you thought it would last sprint – then it will also take 3 x as long as you think the next sprint. No matter how much more effective you think you’ll be this time 😉 Trust the history and use things like Yesterday’s Weather to guide your estimates in the next spring.
Hope this helps!