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.
Interesting idea, but how do you get business to sign on to it? Without signing up for stories, or committing to a certain number of points, for an iteration, it is hard for business to accurately judge how much work is likely to get done. As least on most projects I have been a part of, this makes business very nervous.
Also, I as a developer immediately recoiled at your post. I don’t really like people telling me what to do. I like having a bunch of stories on the wall from which I can choose. This way I feel that I am, just a little bit, in control of what I do. With the idea of a backlog, I am just a code monkey taking the next available card off the backlog (I realize that this is the reality anyway and I need just get over my little hang up about control) with no control about what I can and cannot do. To me, this simply makes me a toaster, toasting up the next batch of bread.
For me, I like the ability to choose my next story. Maybe I have just spent 5 days on a single story and would like something quick to work on. Or maybe, I have spent several days in one area of code and the forth story down is in the same area allowing me to do it quicker. Your backlog method doesn’t allow for this. I have to do the next story regardless.
It also doesn’t take into account the idea of best person for the job. The next available story may require a senior dev to implement, but the next available pair consists of two junior, newbie devs.
I am playing a little bit of devils advocate on this, but I would also genuinely like your insights as well. I think it is an interesting idea, but I have also seen it abused and rejected.
Hey Chris, Thanks for the comments. Perhaps I was remiss in explaining how I actually use the backlog.
For me, I like to use the bucket analogy: I have a bucket of the top (eg) 5 stories that can be played (ie have been fully analyzed). As a developer, I get to pick which of the 5 most important stories I want to pick up, on a first come first serve basis. That means that I don’t pick up the most important story, but one of the top 5 stories. Of course, I would hope that the developers would work as a team and so if a particular story was best left to a certain person/pair, then the team would work out a way to make it happen.
Oh yeah, and the bucket doesn’t get refilled with stories until it is completely empty (any issues that relate to stories that have not yet been signed off can always be added to the bucket).
Who gets to decide which stories are in the bucket? It is a decision made in-conjunction with the business and the team.
The trigger for the BA to start analyzing the next lot of stories is not defined by a day of the week, but by how many stories remain in the bucket.
In regards to how can you get the business sign on to it – why wouldn’t they? What advantage do they get by the team signing up to stories – even worse, what message are you sending when you don’t complete all that you set out to complete?
The most important thing that the business needs to know is : when will I start realizing the value for the work that is currently being developed? So, instead of basing this date on the unknown, we can base our date on actual figures (how much work have we already done, and based on this velocity, what is the expected finish date).
I have worked at clients where we have done this, and they have loved it.
Hi Sarah,
Thanks for the answers. I have a better understanding of what you were talking about now. I like the bucket idea and can see how it can work.
As per your second comment, the client I am at now, seems to want to know exactly what will be accomplished each and every iteration. Part of the problem is that the scope for each iteration has not been decided until after the iteration has started. This makes it very hard to put stories into buckets. In addition, the client, or BA on the team, prioritizes the stories as “must haves” and “should haves” and we are expected to implement all of the “must haves”. Basically, the client has a certain amount of stories that must be implemented for each 4 week release regardless of the velocity of the team. As such, I cannot see the client going along with a idea where we do not commit to doing all the “must have” stories.
I have a few problems with your post Sarah,
First “The real problem with applying this pressure arbitrarily”. If the team determined to strive for a target, then who applied pressure except themselves and what was arbitrary about it?
Second “if you do acheive the target, you generally do not increase the target for the next iteration” Why not? And who is ‘you’ in this quote? I do.
Thirdly “when you achieve the target for the iteration, generally the next lot of stories are not ready” why not? Mine would be, or else I would acknowledge a process problem that needs to be looked at in the next retrospective.
I think you have criticized implementations of the iteration idea which are all flawed. A team that does not have stories ready for the next iteration has a problem that is not centered on that fact that they do iterations, but perhaps centered on a disconnect between story creators and story implementors. A team that signs up for stories then feels pressure to do more next iteration, may have very healthy reasons for wanting to do more next iteration. It could be totally team motivated just as it may be when using a kanban system. And, to be honest, I don’t know why a team would regularly hit their objectives and not choose to try and increase their target.
This is not meant to knock kanban and lean, only to say, I don’t see any problem mentioned above that is not solvealbe from within an iteration based process.
Jeff Santini
Pingback: scriptworld.com.au » I don’t believe in signing up to stories for an iteration