Agile antipattern: Burndown “wall”
Does your team have an iteration burndown chart (giving credit only for completed stories) look like the one to the left? If so there are a couple of possible explanations. Last week I blogged about how this could be a symptom of working on user stories that are too large. However, there is another possible explanation, and it is one that is FAR harder to solve. The culprit is pushing testing to the end of the iteration. The difference between the two is the steepness and abruptness of the wall. When testing at the end is truly being done there are no stories finished until the last couple of days of the iteration while large stories pushes most until the last half of the iteration. See last week’s entry on large stories to see the subtle difference in the burndown charts.
This is basically a version of the code freeze during an iteration antipattern. It is all too common for an organization which switches from waterfall to agile to continue to try to do testing the same way it had been done previously. This generally is done by having a handoff from development to testing during the iteration. Since waterfall tested large chunks of code, most organizations have developers write as much code as they can prior to sending a large chunk to testing. In order for this to occur the development goes for as long as possible during the iteration. Stories can’t be completed until they are tested, so all of the completion of stories happens in the last couple of days of the iteration. This forms the burndown “wall” shown in the sample burndown chart.
So what is wrong with having a burndown wall if everything gets completed? I’m going to surprise you and say there is still a LOT wrong even if everything gets completed in this structure. Here is a list of issues you probably want to look at if this is your current situation:
- What are the developers doing while testing is going on? They SHOULD NOT be working on the next iteration.
- If developers are spending their time fixing the defects found during testing how do you guarantee all the defects will get fixed and tested in time for the end of the iteration?
- What happens if testing runs up against a big problem and can’t finish testing the stories prior to the end of the iteration?
- If there is pressure to finish testing in time does testing subconsciously cut down on the breadth or depth of testing?
- What are the testers doing during the early part of the iteration when the developers are writing a pile of code?
These are real concerns and in my experience one or more of them will cause significant issues in almost every iteration. If a team actually manages to overcome all of these issues in the majority of their iterations then there is still one more question to answer: Is it the most efficient way?
Team after team after team has proven it is not the most efficient way to do things. When teams start doing things differently using Acceptance Test-Driven Development (ATDD) using automated tests they are much more efficient. It also gives them the ability to accept stories every day. Being able to accept stories every day gets rid of the wall and makes a more classic looking burndown chart. Knowing things are completed and working every day will help the entire team feel better about how they are performing.
Until next time work at Making Agile a Reality® by integrating testing and development so stories can be accepted every single day and see how much your team can improve!