Monthly Archives: January 2014

Indian Planning Poker

#NoEstimates,

When I first heard of estimating work items – let’s call them stories – with Story Points I was like “WOW!! That’s amazing!! No more question about how long it will take! Just estimating the relative effort, it really is a good idea!”

Then I discovered Planning Poker, and again was amazed by how it can solve Asshole Driven Development issues (me being the asshole most of the time). I immediately decided to apply it with the team I was in charge of. We did ONE session, and everybody agreed that we were wasting our time. Yet we learnt a couple of things then:

  • We could easily treat small stories, the ones worth 1 or 2 points
  • We could not easily decide about big stories, and almost always decided to break them into smaller stories

All around the Web you’ll see that people recommend not to use the bigger cards of your planning poker deck, and to only keep the 1/2, 1, 2, 3 ones or so.

So we decided to give a try to T-shirt-size estimates, which was basically like keeping only 3 cards in our deck : S, M and L. We did ONE session, and everybody agreed that we were wasting out time. Yet we learnt a couple of things then:

  • We could easily treat small stories, the S-sized ones
  • We could not easily decide about big stories, and almost always decided to break them into smaller stories

Now here is the thing : we had a product to build and we wanted to now how long it would take to build some of the pieces of it (we are not discussing why here). We realized that we could not give any (accurate) estimate to answer that very question unless the pieces were small enough.

So we decided to always work on small-enough pieces of work. Obvious.

Now if for some reason you believe that you need estimates, what you can try with your team, during your next Sprint Planning Meeting, is a session of Indian Planning Poker. You actually only need one card in your Planning Poker hand: the thumbs-up card. Stick the thumbs-up card on your forehead if the story is small enough, or as small as usual, and not if not…and tell me about the results.

Post-Agile : Software Development As A Service

#NoEstimates, , ,

Maybe a new way of working for post-agile organisations

I wrote most of this article long ago but decided to keep it as a draft until recently. I actually thought that was more of an utopia than of a real, possible thing…but this changed after I watched Neil Killick’s talk on #NoEstimates.

I’ve been practicing software development in a Kanban team for several years now, around a single product. A first observation I want to make here is that current “Agile” way works fine with long-term projects, at least if :

  • you build a stable team
  • you slice the work into small SMALL pieces of work
  • you try to keep the work items of the same size, asking simple questions like “Is this work item as small as usual?”
  • you limit work in progress at every level of your process
  • you get rid of “expert” effort estimates and use historical data, statistics and probabilities instead (possible because you built a stable system thanks to the first 4 points)

When I speak to people working in web agencies or other kinds of software development shops, they often tell me it’s not going to work with small projects, when teams must work on several projects at a time, for several customers. They also tell me about contracting problems : how to be Agile – and what are the benefits of it – when dealing with fixed-scope kind of contracts?

That’s why I’d like to describe my hopes for a post-agile world, hopefully solving the issues above, by describing the kind of practice I’d like to see emerge in the years to come. I call it Software Development As A Service. It goes like this:

  • The team implements some kind of Agile/Lean principles so as to get a stable process, like what I succinctly described above.
  • We consider the team as a whole, a system converting customer money into customer business value at a (statistically) predictable rate.
  • The customer and the shop agree on some sort of Service Level Agreement based on lead time distribution for the given team. Transparency is compulsory here.
  • The contract becomes a fixed-cost contract

So I guess that post-agile really is about customers becoming agile too, and embracing the fact that software development is partly made of uncertainty.

If you have any thought on that, feel free to leave a message here or on twitter.

How good are your estimates?

#NoEstimates,

uroboros
An Agile iteration often goes like this, whatever the framework you are familiar with:

  • the product owner prioritizes the backlog of work items (features, epic, user stories…)
  • the team gives estimates for the top of the backlog, using story points, ideal time, actual time…
  • the team and the product owner agree on what will be done
  • the team actually does the magic
  • the team shows what has been done, and we compare with what was expected

Among any other thing, we often compare the estimated velocity, the number of story points the team thought they would tackle during the current iteration, with the actual velocity, the number of story points the team actually managed to sweep away.

By doing so we try to learn two things:

  • how fast the team goes
  • how accurate its estimates are

Pretty logical indeed : we compare expectations with what actually happened… but… WAIT A SECOND! What are the facts I am talking about? ESTIMATES? I am trying to calculate the speed of the team relying on the very estimates which I am trying to know the accuracy, and this accuracy cannot be computed otherwise than by comparing with the actual speed of the team!

BAM!!! Your head just blew up! You are a uroboros!

Now the good part, because I know that some of you still have their head rather intact. I hear you say “We don’t need to know how accurate the estimates are, we just need to know that they are always the same, based on the same scale“…and you are absolutely right. If the team always estimates work items the same way, we can easily monitor its velocity.

Now say that our team velocity is 20 story points per sprint. The backlog is full of user stories estimated at 1 or 2 story points, but one of the stories is worth 19 points. What are we going to do with it? We are going to break it into smaller stories : there is too much uncertainty, too much risk with such a big story, even if the team could theoretically handle it. Ideally we would break it into 1-point or 2-point stories, because that’s the kind of story the team is used to working with.

If we go a little further, we will realize that what we really need in order to calculate the team velocity is that every story is almost always of the same size, whatever the size, even if our intuition tells us that the smaller the stories are, the better our calculations will be.

So we stop estimating user stories with story points – or whatever – and ask the team a simple question : is this story small enough? or better is this a standard story?

A the end of each iteration we just count the number of stories done and do our math…welcome to the #NoEstimates world!