The lead developers have been experimenting with story points recently. I wrote a few weeks back about how I thought we might decide on the meaning of a point.
We decided that our scale would range from 1 to 377, so that the upper end catches the complex, major projects that we sometimes work on.
Then we decided that we’d start with 1 story point being things we’d traditionally have expected to take a quick, experienced developer about an hour. Working that all the way up the scale, a 377 story point is the sort of thing we’d traditionally have estimated at 6 months or so.
Then we dug around our recent work and our future plans for things that fitted along the scale. We put them all in a big pot and decided two or three for each level on the scale which were the most useful examples for the future for how to size work. We came up with a few useful rules where you might want to move up a level because they make the work more complicated:
- adding a lot of behat and/or unit testing;
- working in an area that is already very complex; and
- working with a third party community / system integration.
We’ve recently been given a single prioritised backlog from our Learning & Teaching colleagues, so we decided to try out our shiny new story points on their list. This morning we played planning poker for the very first time.
We set up a spreadsheet with the business description, a supplementary techie speak description, and a column for each person. Each person then had a couple of days to use the story point exemplars and enter their estimate. Each person hid their column on completion so that no-one else’s estimate was biased.
To be fair, I found I mostly thought in days still and worked back to story points. It’s going to take some time to be able to look at a description and think in points instead.
Today we worked out the median of every-one’s scores, picked the nearest point on the scale and decided what we wanted to announce as our final estimate. I was pleasantly surprised by the amount of consensus we achieved. There were some items with wildly differing opinions but that usually just highlighted that the request was poorly defined still and we had differing assumptions on what we would do.
We decided upon one or two more “rules”:
- If the range is very diverse because the item is ill-defined, we refuse to estimate until we have more detail.
- If the median is the same as the estimate from the person who’s subject matter expert for the area of work, we go with that for our final estimate.
- If the median is one step either side of the estimate from the subject matter expert, that person has final say to overrule or accept the median.
- If the median is more than one step either side of the estimate from the subject matter expert, further discussion is required to clarify and agree a final estimate. There were actually very few stories which fell into this category.
Using this approach we managed to get 6 people to estimate just under 100 stories in just under an hour. That’s a lot quicker than any of us expected. We ended up with an estimate of just over 2,500 story points for 3 months work by 8.4 people. Gut instinct suggests that we might manage about 75% of that. But since there were about a dozen things we couldn’t estimate, maybe that’ll be more like half in reality?
So with my project manager hat on, I now have to work out whether we should have estimated for the “top slice” tasks: support, bug fixing, advice, technical debt stories… We probably should have, but I’m not sure if the same approach works. Especially for “keep the wheels on” server monitoring activity.
And now that I have a set of estimates for most of the things our business partners want, we have to communicate that back to them. There will, presumably, be some iteration while we refine the requirements for the things we refused to estimate, attach names to tasks that no-one thought they were doing but which had high priorities, and drop some stuff off the bottom of the list.
I’m really interested to see what we actually deliver at the end of January, so we can for the first time get a feel for how what our development teams velocity might be. Remind me to tell you about that when the time comes!