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.