The neverending Story Points

Here's my second shot at explaining Story Points for estimation in Scrum:


When I switched to points I decided to if I could meet those two points;
1) find and argument that justify the switch and that will convince the team
2) Find an easy method to use it.


Phase 1: Convincing
It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.
This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.

Phase 2: Putting Points in the Backlog
This step is done with the participation of the entire scrum team.
Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.
Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.
NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.
That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.

Phase 3: Velocity & Estimation
To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.
That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value

Points vs Hours

The pains of task estimation. It makes that warm feeling of starting a new project disappear completely. No matter what's your method, Waterfall or Agile, you have to tackle that features list at the beginning of the project and estimate like there's no tomorrow. It's always too big and all those estimations will enable the team to scope. And so, you get to it. It take all of your team days to get through it and a the same time you know you'll have to re-estimate all of those features throughout the entire project.

I got tired of that. Not fast enough, but after 16 years of estimating with hours I couldn't face another project like that. That's when I gave a good try to the Story Points system. It appeared a bit suspicious so I 'googled' away on the subject. My goal was to find THE reason that would convince any programmers on my team to switch to a points estimation. Lucky me, I found one and here it is:

Behold the one reason to use points over hours when estimating.
>> If you show two different features to two programmers, chances are they will not agree on how long, in time, it would take to code it. They will, on the other hand, always agree on which task is bigger than the other one. <<

It takes us now 2-4 hours to estimate what took us a full week before. Here are the easy steps:
1) Put all the possible stories in a spreadsheet.
2) Create a second spreadsheet that will contain, in the end, your estimated backlog (aka the list).
* In this list, the big stories will be at the top and the small ones at the bottom.
3) Copy the first story into the list. Since it's the first item, just drop it at the top of the sheet.
4) Copy the next story into the list by doing an insertion sort based on the simple question “Is this new story smaller or bigger?”.
5) Repeat step four for all the stories.
6) Giving points to the stories starting at the bottom of the list, by giving the first one 1 point.
7) Using the Poker Planning scale (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100), ask yourself if the story above the last one is in the same scale.
* If it is: Give it the same estimate.
* If it's bigger: Give it the next increment in the scale.
* If it's smaller: Move it down until it fits.
8) Repeat step 7 for the entire list.

Tips:
- Try to make most of the list fit between the included values 1 and 13.
- Sometimes micro stories are at the bottom of the list. Give them the value ½.
- At the top you will probably find some Epics of values 20, 40 and even 100. those will have to be broken down into sub stories latter.

Those stories will never have to be re-estimated unless the descriptions changes dramatically. The velocity of the team can be calculated by the total of points they can burn in one sprint and that velocity normally stabilize after 2-3 sprints. With that value you can also predict how many sprints it will take to complete the backlog.

Go points!

Agile - step 1

In the past, I had some small management experiences, though at the time I thought they were significant. Sure it was easy, I only had to manage autonomous people (See previous post about Planing & Foresight for my definition of autonomous). So as a manager, my real challenge began when I was faced with a team largely composed of young graduates. Some of them were dependent some were autonomous.
In the months before the project started, I prepared myself for this leadership position by reading a lot about the subject. I was convinced to try Agile, or more precisely Scrum. Why? Because one of my previous colleagues was using it for years and swore by it. He gave me some key words like 'Scrum' and 'Ken Schwaber' and I was off, learning about Agile planning, development & management.

We started small with agile. I told my guys we would have a scrum meeting every morning and that we would do 4-week sprints. We set our goals for the first sprint and that was it, our first agile iteration was started. We only did two sprints with a duration of 4-weeks. It was a good length at the beginning because we had to set a lot of basic code and procedures. Later they would be 2-weeks sprints. Also, at that time, we did not have many requirements from our owner.

Owner?

The fact was we didn't have an official owner because we were the only ones using agile and nobody else wanted to participate. So I created a virtual owner in my head. His requirements were derived from the needs of the people I identified as The-people-who-should-be-the-owner and I created my own backlog using Jira. We had no way to calculate our velocity but I documented the results of all the sprints on a wiki page that was shared with the team.

I also had two computer screens setup in plain view on which I had a hand-made manually-updated Excel spreadsheet displaying our sprint burn-down and the status of each task. Yes manually-updated, now is that commitment or what? After some time my people started meeting spontaneously in front of the screens to discuss current problems.

When thas project started people were not accustomed to self-organized team work. But I remember the first day I saw 3 people standing up at a workstation, talking lively and pointing at the computer screen. They were discussing possible ways of solving a problem and planning their work. That was a good sign!