Removing a very abstract impediment: the two week sprint length

At the end of the last year we faced the following situation: a product owner turnover, and the new one coming with a great idea. It happened to be that this great idea was a “happy new year” promotion, and so it would be great if we could implement and deploy it at the beginning of december. Unfortunately, we were at the beginning of the second week of november, and a sprint had just finished…

The problems

• we use two week sprints;
• we needed more time to plan the promotion;
• starting a sprint without the promotion features would lead us to a late deploy date;

The insight

As I could do nothing about the fact that we needed more time to plan the promotion, and as this promotion could bring us very good results, I saw our sprint length as an impediment to deliver the value that our new product owner envisioned. So, I removed it! I proposed a one week sprint where the dev team could kill some tech debits and the product owner’s team could plan the promotion. Both teams enjoyed the idea, given the context, and we did it that way. After this one week sprint, we returned to the usual two week sprint, and implemented the features of the promotion, releasing it at the beginning of december, as it should be, and the promotion became a success!

Conclusion

An impediment can be as abstract and subtle as one can imagine. Even things we know as “agile laws”, as the fixed sprint length, can be bended to serve us better. Of course, before doing that I’ve made it very clear to the product owner that we were going to take this manoeuvre only because of this particular situation, and that we shouldn’t use it anymore, in any circumstance, given that he would have time to plan his releases with a lot more anticipation after this very first sprints of him.

Maintaining the story points scale

After applying the James Grenning’s companion planning poker games to estimate our releases, I became concerned about how to maintain the story points scale in the next estimation meeting, since we’ve dropped the traditional “an easy story as base”, and jumped to “an easy column of stories as base”.

The fact is, the solution is simple. I’ve just brought all the stories of the last sprint to serve as a base, and the team used it as column examples. The difference between this estimation meeting and the first one is that in the first one the team had no base, and just organized the stories in columns of similar difficult. Using the last sprint as a base, the team just slided the new stories under the already estimated stories, using the old ones as parameters. This even eliminated the need of planning poker for a good amount of columns, since we had enough stories as examples.

Also, I was in doubt if I should bring all the stories of all last sprints to use as a base, or just the stories of the last sprint. The thing is, the larger the range of points we bring as examples, the better the team will be able o maintain the story points scale. And also, fresh stories are better parameters than very old ones.

My conclusion is that we can apply the techniques proposed by Grenning every time, obtaining very good estimates every time! Just keep bringing the stories of the last sprint to help maintain the story points scale.

Estimating stories faster and more accurately

In a recently endeavour to find the blogs of all Agile Manifesto’s authors, I’ve found this post of James Grenning about some planning poker companion games. Luckily, we were about to do a release planning for both Brasigo and BlogBlogs here at WebCo, just the perfect opportunities to try a new approach to estimating.

The results:

• 20 stories estimated in just one hour!
• much more coherent estimation!
  
• much more accurate estimation!

Why?

• faster due to the great amount of example stories per column of similar difficult, facilitating the comprehension of everybody;
• coherent, because the team compared almost all stories against each other to correctly sort them in columns of similar difficult;
• accurate, also due to the great amount of example stories per column of similar difficult, so that each column had much more information than a single story could give in an usual planning poker game;

Conclusion

I highly recommend this method! Not only for release plannings, but for all estimation sessions. It is deep enough to do always.

Explaining the value of estimation to the team

Before the next release planning of Brasigo and BlogBlogs, I called each team to show them the hour-glass metaphor. The message I wanted them to understand was: estimation gives us predictability, and this is crucial for every business, including ours.

To achieve this, I played the hour-glass estimation game exactly as I did with the product owners. After the third sprint, they correctly estimated the total amount of time needed to pass all the sand from one side to the other. And then I said: “Do you know what we did? Before the end, we know how much time it will be needed to pass all this sand to the other side. This is very similar to release backlog estimation: after a few sprints, we have a very good estimate of when we will finish it! This gives us and our stake holders predictability, and this is crucial to our business!”

Both teams liked this metaphor very much, and they truly understood why we need to estimate, and why we need to take it seriously. Also, I felt that they liked to be with me in a meeting explaining this, and also that they liked the gaming thing. Based on that, and on this recently post that I read, I’m now researching some other kinds of games to play with them. But this is the subject of a future post.

Explaining empirical process control to a product owner

The day after, I called each of the product owners of Brasigo and BlogBlogs, separately, and showed them the hour-glass metaphor. The message I wanted them to understand was: as the current release evolves, we will have a good estimate of when it will be finished, with its current scope, and that is empirical process control.

To achieve this, first I played the hour-glass estimation game: 3 sprints of 30 seconds each, so that them could make four guesses for the total time needed to pass all the sand from one side to the other. At the third sprint, both of them made the right guess, and I stopped the game.

Then, I started it again saying: “Imagine that this sand is the product backlog slice corresponding to a release. At the beggining, the developers have no idea of the time needed to implement it. But after some iterations, usually the team will have a very good estimate of how much time they still needs to finish it. And that is empirical process control.”

After that, both of them had an instant insight!

Hour-glasses and empirical process control: a good metaphor

One night I was paying my bills, and suddenly I saw a tiny hour-glass on my desk. My wife probably left it there for some reason… But after I saw it, I wanted to know how much time it would take to pass all the sand from one side to the other. Curious as I am, I turned it and started to count. After a few seconds, like a flash, I stopped it, putting it with the two sides on the desk, because I saw Scrum happening right in front of my eyes, clearly as water, and in a sufficiently easy way to explain it to anyone else! Actually, I saw not only Scrum, but any empirical process control method.

What happened? I didn’t know how much time it would take to pass all the sand from one side to the other. This situation is like an unestimated product backlog: you just don’t know how much time it will take to build it. So, I made a guess: 5 minutes. Then, after 30 seconds, I stopped the hour-glass, looked how much sand passed, and made a new guess, given the amount of sand and time passed. This was my first sprint! After 3 sprints, that is, one and a half minute, half of the sand had already passed. So, my guess to the total time needed was certainly 3 minutes, and that was right! With only half of the sand in the other side, I had the exact amount of time that the hour-glass needs to pass all the sand from one side to the other! WOW!

That’s it! Empirical process control for dummies! =)

The “Agile Inquirer” origin

Today I’ve decided to finally start a blog. The idea of this blog is to be a collection of short, direct and objective posts about agile software development. I’ve chosen this title according to this definition of the Cambridge dictionary:

inquiring
always wanting to learn new things, or (of someone’s expression) wanting to know something:
You have a very inquiring mind, don’t you.
He gave her an inquiring look.

And following the short, direct and objective directive, this post ends here.