I have a client that has a tendency to get nervous about half way through each iteration because the burndown chart isn't tracking. Each member of the team is giving a daily estimate of how much work remains. The catch is, each one is accounting for some uncertainty in testing/integration, so they are padding their estimates with a buffer.
The problem with the buffers can happen in agile or waterfall projects. I can remember the old days of project management...I would be working on the schedule. I'd go to the various team members and ask them how long their tasks would take. They would add in a "fudge factor" to account for any uncertainty. Then when it came time to do the work, they would procrastinate on starting, knowing this buffer was there. However, when they did start (later than they should have), they would come across the uncertainty and now their buffer was gone and the project got behind schedule. This phenomenon was referred to by Eliyahu Goldratt as Student Syndrome.
The trick of course is not to put the buffer into each estimate in the first place. In my client's case, what has happened over the last couple interations is that all of a sudden at the end of the iteration, everyone gets their work done, doesn't need the extra buffer, and the burndown takes a sharp nosedive. The only real issue is that the PM taking unnecessary steps during the iteration to try to fix a problem that doesn't exist (and try to explain what is happening to management).
Freaking out when the burndown isn't going down steadily is pretty common. I've seen managers believe that nothing is being done, though this is often not the case.
ReplyDeleteSounds like a great time to talk with management about velocity and using it as the forecasting measure, and not being too concerned with what is going on inside the sprint. Management should be mainly concerned with the ultimate result of the sprint.