If there is one thing that I hate about how a lot of Agile projects are run is the notion that you need to sign up to deliver certain stories/ a certain number of story points for an iteration. I find this to be detrimental on so many counts.

Firstly, if you don’t achieve the target then you feel bad, and feel really pressured the next iteration as now the project is running late. This tends to effect junior/inexperienced/graduate developers more than their experienced colleagues; they feel the pressure and so they work late to finish stories or (as I have once witnessed) coming in over a weekend to make up some ground. The real problem with applying this pressure arbitrarily is that most teams do not do root-cause analysis to find out why you didn’t achieve said target and work out what is slowing the team down/how they can go faster*. 

Secondly, if you do acheive the target, you generally do not increase the target for the next iteration which means that there is no chance for an s-shaped curve on the burn up graph (ie you don’t have the opportunity to go faster); and

Thirdly, when you achieve the target for the iteration, generally the next lot of stories are not ready, so you don’t have anything to work on and you tend to waste days. It also means that you are more likely to stall finishing the last stories (gas expands to fit the size of the room; developers expand the time it takes to complete a story to fit the time they have available)

Lean and KanBan offer an alternative to this approach: the backlog. Essentially, iterations are demarkations in time to allow you to reflect on your processes (yes, I know that in KanBan there are no iterations, and this reflection happens on an on going basis). To know what work needs to be developed for a day is all about prioritizing the top X stories (eg top 3 stories) in the backlog. That way, there are always X number of stories that have been analyzed and are ready to develop, the stories in development are the most valued stories (whether the value is to the business or to de-risk the project) and there is no bad pressure because you didn’t achieve what you set out to achieve. The only question that the team needs to be constantly asking and answering is:

"What can we do to make us go faster?"


  • A retrospective as I detailed here may help in this case.