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

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.

persistence stories arrive late

In one of last week’s architecture workshops (see databases as life-support for domain objects) our group briefly considered how the new product line might emerge gradually from a series of user stories. The Product Owner agreed that stories about persistence would probably be placed relatively far down the backlog, behind the stories that deliver the first several tranches of usable business value. The Product Owner wants to see and understand the business logic first, and only later will he care about “non-functionals” such as persistence and levels of service.

So if we truly design and build our application story by story, without being tempted to predict what the Product Owner will want in the future, then the database will not exist until after many of the domain objects. This is business-level support for @jbrains‘s assertion that the database should be developed last. And it knocks sideways the idea that the ‘architecture’ should be designed at the start of a project.

Update, 9 Nov 2016

I’d like to thank Joe Rainsberger for taking the time and trouble to resurrect his article, which had disappeared from the interwebs sometime during the 11 years since I originally wrote this post.

time-boxes focus the mind

Two events this week convinced me of the power of timeboxing. In both cases an activity was in danger of drifting, such that the effort expended would far outweigh the value (if any) returned. And in both cases we applied timeboxes that seemed crazy at first glance, but which created the focus to get the jobs done.

In the first case, a real-live paying customer reported a bug. The current release plan says we’ll continue with 2-week iterations until mid-June, at which time the new release will be made available to all comers. But it was important to get an interim release to this particular customer much sooner than that. In fact, as soon as possible. Yesterday.

Now this team are currently making great strides towards agility, but their product and their code still show strong traces of the past. So the first estimate to produce the bug-fix release was that it would take a couple of hours to fix, and then tradition requires the entire team to test any release for 5 days! This estimate seriously crippled the release plan, pushing important stories out past the projected June release date. This, in turn, created an “atmosphere”, in which everyone looked for places to dump the blame. A project that was riding high was suddenly brought crashing to the ground by one defect that had been inserted into the code long ago.
Continue reading

energising the iteration review

Today was the last day of the iteration, and so I decided to make some changes for the iteration review meeting. One month ago the day had gone very badly (see the product owner must pull), so today we needed to recover a great deal of lost trust, credibility and morale. Here’s what we changed:

we moved out of the boardroom
Previous iteration reviews had been held in the boardroom. They were formal affairs, in which the development teams sometimes seemed to be almost on trial. The imposing setting made the directors – who are the Product Owners for the company’s various products – feel at home and in control. But it made the developers feel as if they had been called into the headmaster’s office. So this time we held the day in the team room. In the engine room. Busy desks, PCs set up for pair programming, information radiators all around the walls, and all dominated by the task board at one end. A place of work, and a change of dynamic.
we didn’t prepare a demo
The tradition had been to prepare a releasable CD and install it on a clean machine in the boardroom; this installation would then be used to demonstrate the increment’s features. We decided that the effort required to prepare all that was greater than the benefit we would gain by “practising” a release and installation. So today each new feature was demonstrated on a developer’s PC. We walked the Product Owner through the completed stories column on the task board, and for each story we turned to the developer who knew the most about that story. The developer showed the feature on his own PC, with the audience crowded around him. No PowerPoints, no clean install. But loads of energy. There was a real buzz as each story card in turn was demonstrated – a real connection between the backlog and the working software.
we held an iteration retrospective
After the increment demonstration we held a time-boxed iteration retrospective. A lot had changed since the last iteration boundary, and the team gained much by reviewing the progress it had made. It turned out we had recorded a roughly 20% increase in velocity – and a 100% increase in morale. The whole team committed to measure likely areas of muda in future iterations, and individuals committed to improving specific aspects of their own processes. By the end of the time-box the team really felt like a team.
we had a full backlog
After the previous iteration review we had implemented iterative backlog creation. So after the retrospective our analyst was able to present loads of stories for consideration at the top of the backlog. We put them on cards on the task board, and the Product Owners moved them around until they had selected one iteration’s worth of business value for us to develop next. Instead of PowerPoints in the boardroom, we had the company’s directors physically engaged in the project. The team watched with broad grins as the cards were touched, discussed, moved, pinned, unpinned. At one point we had two directors squatting on the floor looking at the rest of the backlog for comparison. Suddenly everyone was connected.

The day was a complete turnaround from the previous iteration boundary, and the team is now fired up and raring to go…