A #noestimates follow-up

It dawned on me this morning that I left out quite a bit of detail from my post about my experience with trying the #noestimates approach with some of our projects.

History

I’ve been a Scrum Master for a couple of years now. When I was first certified, I was working for an online accountancy firm with a 15-strong team of developers. We had a core cloud-based product, serving around 5,000 clients. However, the audience for our sprints were internal Product Owners and Stakeholders. I mention this because budget was not a major concern for the projects I worked on. Deadlines were generally the main constraint, but even then it was OK to slip.

Like many Agile projects, we started using Story Points as a means of relatively sizing our stories. We used Planning Poker until consensus was reached. We never estimated the tasks for a story. We tracked velocity over the course of several sprints and used that velocity to plan future sprints. This worked very well at the time because the team was generally consistent. However, towards the end of my tenure there, we ditched story points and we ditched velocity tracking. Instead, we broke down stories until they were all roughly the same size. After doing this for a few sprints, our velocity was effectively N stories per sprint.

Today

With my new employer, things are very different. I work at an agency where clients expect estimates; they have budgetary constraints; they think they know what they want. The development team is effectively a pool of developers from which project teams are created for the duration of a client project. Tracking historical velocity is therefore unwise, as not only is the team different each time, but so is the nature of each project. Sometimes we’ll use Java; sometimes we’ll use something else. We also have to give the client a rough idea of what they can get and when they can get it. We have to cost things for them. A very different environment from my previous employer.

We still do the occasional fixed-cost-fixed-scope project, but we’re making efforts to phase them out because they invariably end up costing us more, or the client more; and the culprit is normally less-than-well-understood scope definitions and slightly-optimistic estimates.

However, we also have clients that have an idea for a product and are willing to work with us to make that idea become reality. There are still budgetary constraints; there are still time constraints. But rarely does the client demand that a fixed set of scope requirements are met. This is good. And constraints are good because they help drive creativity.

Sprinting

So, this brings us to now. In my previous post I was talking about how the team had endorsed the use of the principle of #noestimates (it’s not a process, nor a framework – but a key to unlocking different ways of approaching work on a project and creating a different kind of client relationship). The client for whom we are delivering a product has worked with us before. In fact, their last product consumed around five 2-week sprints, so they got very used to working with the team. We used relative story point estimation for those sprints but you know what? no one tracked velocity; no one asked what the numbers meant or how they translated to days and hours. We used them internally to indicate if a story was big or not, but at the end of each sprint we were judged on what we had delivered, not how we had delivered it, or how long it took. (It so happens that the team consistently finished stories early and brought in new ones before each sprint ended. Whether this is a sign of under-commitment or otherwise, is difficult to say.)

Sprint
Charts look good, but that’s it

That same client came back to us with a new product idea. It was even more nebulous than the first product we’d delivered for them, consisting of nothing but a JPEG consisting of six rectangles! However, the client had learned a lot and when we looked at the backlog they had produced, we were impressed. Sprint planning took about two hours. Each sprint lasted five elapsed days. By the end of the first sprint, we’d delivered the essence of the desired product. They had a week off to think about stuff, and then when we restarted with the second sprint the backlog had been tweaked, stories had been re-prioritised, some had been ditched altogether. We finished the product with a couple of days to spare at the end of the second sprint.

I put this success down to the team; they liaised daily with the client; they reacted to feedback rapidly; they deployed pretty much constantly; they kept stories small. And as our most recent retrospective revealed, they felt things were made easier by not having to estimate.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s