#noestimates, Agile, Other blogs

Scrum Master Toolbox Podcast

No Comments

Scrum Master Toolbox Podcast

If you haven’t come across the work of Vasco Duarte, then I recommend you tune into him and especially his take on #noestimates (I consider him one of the three #noestimates musketeers, along with Woody Zuill and Neil Killick).

Some time ago I was invited onto his Scrum Master Toolbox Podcast to talk about the typical issues that Scrum Masters face. I urge you to check out the other podcasts; there are some very enlightening conversations on there from some great Scrum Masters including Neil Killick, Woody Zuill and Henri Karhatsu.


A #noestimates follow-up

No Comments

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.


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.


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.


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.)

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.


The [long] road to #noestimates

1 Comment

One of the teams I serve has just finished its second retrospective.

I really enjoy retrospectives with this particular bunch; we have a lot of respect for each other and it shows. Our retrospectives are normally light-hearted, but with a tinge of seriousness.

I’ve been using the Speedboat Game more recently, where team members stick Post-Its against the motor (what kept the sprint running well), an anchor (what held us back) and an obstacle (the long-range issues which we seem to hit every time). I mix things up a bit by asking people to volunteer to do the drawing, which always helps keep things fresh. In fact, I’ve seen the speedboat evolve into a X-wing fighter, with the Death Star being the obstacle, and tie-fighters holding us back. Great stuff.

But I digress.

In this retrospective, we did our normal thing, and the team started putting up their stickies. When I came to read each one out (for further discussion), I grabbed this one:


I asked the author. and the team, to explain. “It really helps that we don’t estimate our stories any more. It seemed like a waste of effort.” “When we used to estimate. we would fill the time to match the estimate.” “We’ve been delivering all our stories consistently – why estimate?”

For this project, we started with the premise that if a story seemed too big to handle, then we’d split it. Of course, there is estimation taking place, but at no point would we attach an estimate to it, not even with a relative point system (which I still use on other projects). Instead, we would ensure that as each story is finished (not Done), we would push it to the client and encourage the client to give us feedback or mark it as Done as soon as was humanely possible. We gave our client access to our Scrumwise tool, and once they’d seen a story, they would move it to the Done column. If they have feedback, they use Basecamp to report it and normally within minutes the team has reacted and pushed the new code. This method has worked awesomely for us.

During Spring Planning, we discuss each story and the team uses gut feel (and, where applicable, Yesterday’s Weather) to decide to commit, split or bin off (get rid of the story). We’re in near-daily contact with the client. We set expectations up front about the sort of involvement we expect from them.

At no point during the two sprints we’ve run so far has the client asked us to tell us how long something will take. Instead, we’ve worked with the client to ensure that the stories are well understood and broken down; we’ve negotiated with the client that early feedback is the key to obtaining an awesome product. There are the occasional hiccups when the client suffers from Overworked Product Owner syndrome, but in those cases, the team moves to the next story while I as Scrum Master apply the pressure on the PO to get his feedback to us.

I know from experience that not all clients can work with us this way. With this particular one, we looked at what they had in mind for a product and we said something along the lines of, “Give us two sprints and we’ll produce something meaningful for you.” This worked well in this particular case because the client had worked with some of the team’s developers on previous products, so they had trust in us. In fact, they insisted that the team remained the same across products. So I don’t deny that this has helped us embrace #noestimates; some clients simply can’t operate without some sort of upfront estimate. But that’s a subject for another day.

What brought a smile to my face during this retrospective was the fact that the #noestimates approach had been endorsed by the team. In the old days, I would’ve asked, “So…what do people think of no estimates?” but now I keep my mouth shut in order to give the team space to talk, and I’m so glad I did.