Agile Anarchy update

To new followers of this blog (and others):

I no longer write here. You can find links to my various writings at tobiasmayer.uk

Please find me there—and thanks for following.

(updated 31 May 2019)

Agile Anarchy has moved…

Nothing happening here. Check out Agile Anarchy—the tumblelog edition.

Scrum, enough already

Continue reading

Marriage, but

Continue reading

The Youngest CSM

Continue reading

Scrum is not Project Management

Continue reading

Don’t Have Meetings

Continue reading

In Praise of Unpreparedness

Continue reading

Beyond Estimation

Note: An edited version of this essay appears in the book, The People’s Scrum, published by Dymaxicon, May 2013. 
———-

Most Scrum teams these days are taught the estimation techniques described in Mike Cohn’s Agile Estimation book , namely the estimating of user stories (aka requests) in relative size using techniques such as planning poker, and the estimating of tasks in hours. I eschewed task estimates a few years ago, see Unearthing Impediments by Doing Less. More recently, perhaps over the past 2-3 years I have found less and less need for story estimation. I find the practice is time-consuming, creates unnecessary overhead, and adds very little to a team’s ability to make commitments, and meet them. On occasion it has caused irritation and distress in both team members and customers who simply do not see any value in it.

I am not against having a team experience distress, or breakdowns as a method of learning, but in the case of estimation I don’t find it worthwhile. There are better things to focus on, such as writing well-formed user stories, requests that have clear value and conditions of acceptance. The dialog around defining the conditions of acceptance tends to cause requests to become smaller. It is very hard to create and agree on a set of acceptance criteria for large or vague requests.

If velocity is important (and I’m not convinced it is) then it can be done through a count of completed requests. When requests are kept small they tend to be much of the same size. If they are not, it may indicate a lack of clarity both about what we are asking for (the PO) and what we are committing to (the team), so rather than slapping on a big 21, 34 or 55, it is better to spend a little more time, think a little differently and refractor the request down into a set of smaller requests. I always recommend to teams that they take on between 5-10 stories per sprint. Somehow this seems to work out no matter the domain or the length of sprint. Having smaller requests also aids the prioritization process as we learn what need not be done.

I have come to believe that estimation using any number system, whether it be ideal hours or relative points (which ultimately map to time) is compliance to an outmoded system, a way of appeasing old-school management who are unable, or perhaps more accurately unwilling to think beyond data points and (empty) promises.  There is still a mindset in the Agile world, as much as there ever was in the PMI world, that teams can somehow commit to both time and scope. Estimation, as it is commonly done perpetuates that myth, or at best does not challenge it.

A team should commit on gut feel more than on data points. We are feeling people as much as we are thinking people, ironically the former may be more important when working in the knowledge industry. At the end of each planning meeting the team members should ask the question, do we honestly believe we can meet the commitment we just made? If the answer is not a resounding yes, then reduce the commitment until it is. And no, this does not result in teams under-delivering. I have never once experienced that phenomenon.

Moving away from the obsession with numbers allows us to begin to trust our instincts, to draw on our individual real-world experiences and our “team intelligence” to give truthful responses to the “when will it all be done” question.
If you find your team is bound by Estimation Think, I challenge you to spend a few sprints not estimating, but spending the time instead to make the stories in your backlog smaller, each having a clear value statement, and reasonable conditions of acceptance. You may be surprised by what happens.

The Retrospective is Now

Continue reading