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

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.

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.

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.

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.