Estimating user stories: the 5 day challenge

This is a quick note about an idea I’ve been using with a few software teams during the last couple of years. I also spoke about it briefly at the Scottish Ruby Conference this week (video at the bottom of this post). If you try it, please publish your experiences and link to them via the comments here.

TL;DR — don’t guess the size of a story; fit the story to the size you want.

Continue reading

Advertisements

a week isn’t long to wait

A very important part of the process of incremental delivery is the weekly commitment. Each week the product owner and the development team should agree on an increment of value. The development team will commit to delivering that value, and the whole organisation should respect that commitment.

So if anyone wants the team to do something different – a few hours’ support, or an urgent feature for a desperate customer – they must expect the team to say ‘no’. Because the team has promised the product owner that it will spend its time delivering the agreed value.

The time to choose what the team does is at the weekly planning. Or preferably before the weekly planning, in conversation with the product owner. If you anticipate support interrupts, get them allocated into that week’s increment. And if you failed to anticipate them, find a way to let the team deliver on its commitment anyway. After all, on average you’ll only have a couple of days to wait.

The way to influence how the team spends its time is to influence the product owner. To directly ask the team to do something that isn’t in the increment is to fail to respect their commitment to the product owner. No-one performs well when asked to steer in two different directions at the same time, and no-one should be asked to decide where their loyalties lie. Agile software methods all place the product owner at the gateway between the team and any parties who may wish to use their time. Entering the team’s room via the back door breaks the fundamental structure of the agile process, and will likely lead to confusion, disaffection, loss of morale and loss of productivity. And all for the sake of a couple of days…

looking for patterns in the churn

One of the projects I work with has very high churn in the backlog. There are repeated and frequent seismic shifts in the project’s priorities, and each time that happens a whole slew of twenty or more cards instantly appears at the top of the pile. And a couple of times the entire backlog has been junked – sorry, archived. Naturally this all has side-effects, some good and some not so good.

It’s important to note that this project is considered a roaring success. The team has achieved amazing things in a short time. And its ability to cope with the backlog churn – while maintaining velocity – is remarkable. And yet the churn is disorienting: the team’s retrospectives regularly discover that individuals feel the project is out of control, or directionless.
Continue reading

the ten-minute rules

When I’m coaching, I often find myself setting little 10-minute targets to help teams break old habits. Here are some of my ten-minute rules for software teams:

  • check-in working, tested code at least every ten minutes;
  • when pairing, switch driver after at most ten minutes;
  • if a design session lasts more than 10 minutes, it must be attempting to solve a problem that’s too big to be a single chunk.

Because to make these work effectively, a number of other things have to be in place. Such as a fast build and “vertical slice” thinking.

managing expectations

Yesterday I used the phrase “In that case, we’ll need to manage their expectations.” I’ve used it a million times before. Today I feel it smells bad. Here’s the background:

A new team is just starting a new project, to develop a new product ready for a trade show in just over six weeks. A great deal rests on this new product being a smash hit at the show, and the Product Owner has a glorious vision involving gaping mouths and million-pound cheques. The concept for the product is genuinely stunning, but there are only six weeks in which to develop it.

We estimated the stories in the brand new backlog using a very simple points system. The points relate to nothing but each other – “this seems to be twice as hard as that, so if that’s a ‘2’ then this is a ‘4’.” And being a new team, we have no idea how many points we’ll get through in a week. When we know our velocity, we’ll be able to draw a line in the backlog and tell the Product Owner what he can expect to be able to demonstrate at the show. But as of today we have no velocity, because this is Week One. So we can’t draw the line. So he may already be expecting too much of us…
Continue reading

developing a sense of urgency

In Estimating Project Durations – not Deadlines, Frank Patrick rails against the demand for “accurate” estimates and the ensuing deadline culture. His very good article reminds me of something I’ve been meaning to post for a while, so here goes.

On this particular project, just over a month ago, I decided to try an experiment. Our process involves taking user stories and breaking them down into small development tasks which, being small, should be relatively easy to estimate. But iteration after iteration we were squeezed at the finish post because some tasks had taken way too long. I had no idea what the cause might be, but in my mind I coupled it with the team’s overall apparent lack of urgency. Things just drifted along.

So just before the next iteration’s planning meeting we had a team workshop. I explained the critical chain view of estimates, and we decided to give it a go. The team recognised that historically all of its task estimates had been conservative. Fear of being late had made us create estimates that were universally over at the 90-100% end of the range of possibilities for each task. That is, each estimate created a 90-100% chance of “being right”, of finishing within the estimated time. So we had stacked each iteration with 15-20 small tasks, each of which had only a small chance of being late. And each time, one or two were indeed late. No-one knew why, and yet those few late tasks ate up the iteration’s slack. Every time.

So we removed the pressure on any individual task to be brought in “on time”, and we switched to estimating every task at the 50% point. That is, we did our usual conservative estimates and then halved them! The results were amazing, and have been repeated now over three iterations:

Most tasks are now finished by the 50% point (partly because the developers treat the estimate as a timebox – “I’ll do what I can in that amount of time, and then see where we are.”) And those that go over just eat into the project buffer a little. In fact, we’re now getting a whole load more tasks done in the same time. Critical chain estimating has eliminated the effect of Parkinson’s Law and simultaneously created a sense of urgency.

I’d love to know whether this works for other software teams. So if your iterations consist of a suitably large number of tasks, and if your estimating is generally conservative (read “fearful”), just try halving every estimate and see what happens.

Update:
This article provoked a great deal of discussion on the Yahoo scrumdevelopment list – read a summary in my follow-up post.