Woodland creature story sizing in practice

Today was my last day in Oslo, a chance to reflect on NDC and spend some time with the people I met. I had the pleasure of spending my last day with @toddhgardner, @mgasca, @reverentgeek and @timgthomas. Somewhere between the Maritime museum and the Viking museum we got talking about estimating, velocity and feature sizing.

I mentioned that some time last year our team stopped estimating features in terms of hours or days, we started talking about woodland creatures instead… because things makes more sense that way. Actually – we try not to use the word estimate at all.

Rather than explaining how this works myself, I’ll point you at the post that gave us the idea:

http://blog.risingtideharbor.com/2011/05/woodland-creature-story-sizing.html

12 months on: We are still slaying dragons!

So how have we applied the ideas that @mattbarcomb wrote about in our project? We use a much smaller set of animals for simplicity’s sake:

–        Shrew (hopefully this will be pretty quick)

–        Squirrel (looks like a pretty typical-ish task)

–        Badger (probably a fairly chunky piece of work)

–        Bear (I’ll be stuck on this for a while…)

–        Dragon (we don’t know – but it looks scary! We need to do some investigations and break it down into smaller tasks)

The point is that one bear plus two shrews does not equal a release date.

badger

The result is that we are able to set expectations far better with both our internal and external stakeholders. In actual fact, our end users (who are software developers themselves) tend to totally understand why we estimate this way and they stop asking us about release dates. (This is helped because we try to release routinely every Wednesday). They actually quite like it when I tell them about the bears and dragons!

Conversations with our internal stakeholders are easier because we are setting expectations correctly by giving managers (at various levels) a reasonably accurate representation of both the scale of the work and, importantly, the scale of the uncertainty, in a format that is very easy for them to understand – regardless of whether they have a background in coding or not.

Also – it’s kind of fun to talk about squirrels, badgers and dragons at the morning stand-up.

Come to think of it, I have a few bears to attend to myself when I get back to the office. On that note – if you are interested in joining our BETA program for a tool aimed at highlighting all the changes that are made to your SQL Server databases (for example hot fixes on production) please get in touch (@_AlexYates_) or sign up here:

www.sqllighthouse.com

bear

EDIT:

After last year’s trip to NDC I’m really happy to announce that I’ll be back in Oslo for NDC 2015 and this time I’m delivering a couple of talks!

https://ndcoslo.oktaset.com/p-22839

  6 comments for “Woodland creature story sizing in practice

  1. June 9, 2014 at 10:13 am

    For me, an important property of woodland creature sizing is that it frees the development team up to make an ‘estimate’ of sorts. There’s definitely a stigma attached to providing hour/day time estimates for development tasks; engineers can be very nervous about making a rod for their own back by giving an optimistic (or even realistic) time estimate. They fear that a manager-type will then hold this estimate against them, putting great pressure on them to meet an inaccurate estimate they made in good faith. Sadly, this outlook has probably been reinforced by poor management in the past.

    Woodland creatures sizing avoids that estimation stigma. A badger has no equivalent time value and a squirrel has no ‘completed by’ date. Instead, they give the team (and the manager) a good feel for the scale of the work encapsulated by the task and it’s relative risk (Dragon = this might burn our face off).

  2. June 9, 2014 at 1:43 pm

    I love this idea and will be promptly mentioning it to my manager, project manager, and scrum master (yes, that’s three different people, and no, I don’t know why). It will be promptly pondered, misunderstood, and considered “cute” (respectively).

    I have to wonder though if you’re selling yourself short with two significant advantages you have going for you.

    First, your end-users are devs, so they see things from the same (or similar) angle. Try convincing your Marketting end-user that wanting it quickly doesn’t make a chunky badger into a shrew.

    Second, in my experience, business partners and end-users ask about release dates inversely proportionately to the frequency of releases. So having weekly releases would naturally lead to fewer questions about release dates. Can you help explain further how woodland sizing helps with this part?

    • Alex Yates
      June 9, 2014 at 2:11 pm

      Thanks for the feedback Scott.

      Regarding your first point, I’ll remind you that I am a pre-sales engineer – not a developer – so I guess it could be argued that I fit more into the marketing category that you refer to than the dev category. 😛

      It is certainly common for there to be a bit of a divide between the ‘engineering’ and the ‘business’ cliques in an organisation and at Red Gate we have felt this pain at times too. Using woodland creatures is certainly not a silver bullet, but it is one tool that you might like to use.

      In my experience, there is no substitute to regular face to face contact. For example, having a sales person embedded in the dev team has resulted in a lot of learning from both sides. I have observed and learned a tonne of stuff about the engineering process (hence, this blog) and my team have become more aware of the ‘business’ reasons behind the work that they do – which has been wonderful for morale and engagement. Naturally, it helps a lot that we get on quite well outside of work as well. 🙂

      If you know the marketing guys well you’ll be able to make your own judgement about whether they will understand or scoff at the idea of woodland creatures. I certainly would not claim that it is for everyone – but it works for us.

      On your second point, it is worth pointing out that just because we release every week, we still have a long backlog of things that might take a while to complete. But you are right – regular production releases are awesome and they do help alleviate customers concerns about completion dates.

  3. Christian Bahnsen
    June 15, 2015 at 1:55 pm

    The link to the blog didn’t work for me.

    Error message: “Sorry, the page you were looking for in this blog does not exist.”

    • Alex Yates
      June 15, 2015 at 2:35 pm

      Thanks for pointing that out!

      It looks like Matt Barcomb’s blog is down. I’ve asked him about it on twitter as it’s a shame. His blog is quite good.

Leave a Reply to Scott Cancel reply

Your email address will not be published. Required fields are marked *