Story Points and the Heart of Scrum

Last week I wrote, "Story Points are not uncontroversial" and lo, and behold, not a week after I made the comment, I posted essentially the same arguments to the Scrum Development mailing list in response to question about how many man days are there in a story point. Dave Rooney of Mayford Technologies wrote back:

"I generally agree with Peter's points..., except that estimating any development effort in hours is a mistake, plain and simple. You are mistaking 'precision' with 'accuracy' in that case, and any estimation is bound to be incorrect.

"What you need to do is to measure the team's *actual* output, and feed that back into the measurements as the velocity. These measurements need to begin as soon as development starts, and need to be made continuously. That's the only way to introduce any accuracy into your estimates."

I think there are two perspectives here.

On the one hand, I'm totally in agreement with Dave that estimating in story points as an abstract unit is the right way to go and with his observation about the importance of measuring the team's actual output.

But on the other hand, Project Management is always about the Art of the Possible. Getting the project to a satisfactory conclusion under the circumstances, particularly if you are rescuing a project in crisis. I have seen a number of attempts to a implement a pure agile approach fail due to lack of flexibility on the part of the Agile champions or due to resistance from the team.

So we have stick to our principles: Continuous Improvement, Self-organization, Commitment Driven. Taking exactly what you can eat. Eliminate Impediments. These Principles define the practices at the Heart of Scrum. The Plan - Do - Review - Improve Sprint Cycle. A fixed length Sprint with a fixed (or at least predefined) team. A negotiated Sprint Contract between Product Owner and Team. A Definition of Done. If you're not doing these things, you're not doing Scrum.

We can comprimise on practices if we are true to our principles and to the heart of Scrum. User Stories are a practice. Story Points are a practice. We can use them or not if they make sense for our project. (They are also very good practices, and where I haven't used them from the beginning, I have migrated to them as the projects moved forward).

Once you start doing Scrum, the Scrum Master can start prodding in the team to adopt the Agile practices that fully unleash their potential. But I've written why a coach is more effective than a bulldozer and how it took the Team exactly one meeting to raise the contradiction of being told what to do while being told they are self-organizing. So compromise and accommodation is part of the game.

Which brings us to the project at hand. But that is tomorrow's post.

More on Selling Story Points to Management

Useful as they are, Story Points are not uncontroversial nor is this problem of creating a "reference kilogram" for code trivial.

One problem we had on the WLC project was that we had two fundamentally different kinds of work to estimate: HTML Publishing and Software Development. Although we had attempted to have one reference Story Point for everyone, this proved to be elusive. After a few Sprints, I noticed that we had much less effort per publishing Story Point than per development Story Point.

A second issue is that some stories are intellectually complex while others are just time consuming. If Story Points represent complexity, then a simple but repetitive task should get a low number. This is unsatisfying, because such a story will put a higher load on the team, just because it takes so much time.

A third issues was that some developers just did not like Story Points and insisted on estimating in days.

After we had some experience with Story Points, we had an empircal measure of velocity, which we could also use to generate work days ("AT" for Arbeitstage) per Story Point. We discovered that the average of 3.5 AT / SP worked pretty well for us. Those 3.5 days included things like testing, code review, the Scrum-Master's time, and everything that when into realizing that Story Point.

This allowed using the conversion when estimating stories. Having the stories somehow anchored in time was very reassuring to the developers who didn't like Story Points. One they knew the could convert to time, they didn't feel the need to.

This led to a different approach, let the team estimate hypethetical days, but on the Cohn scale. 1, 2, 3, 5....

I think people naturally estimate hypethetical days without being told to. This is the time it would take if they had nothing else to do, no email to read, no collegues asking for help, etc. Most Project Leaders add 50% to the developers estimate, and the difference between hypethetical and elapsed time is usually about this amount.

I have a certain fear talking about hypothetical days to customers. Just a matter of time before they only want to pay for the hypothetical time...

Still, this is not a bad reference kilogram. Something for the Scrum Team to fall back on, in case they don't have any other brilliant ideas. At the same time, we call them Story Points, calculate velocity like if they were story points, and compare stories to each other for estimated purposes. So very quickly, they become real, live story points!

Update: There is no ultimate truth, and this proposal has its naysayers...

What is the difference between Scrum and RUP?

When I present Scrum to customers, I often hear, "yes but we do RUP, that's iterative, so it's Agile, right?"

I spent some time looking at "Project Management with Rational Unified Process" by Gerhard Vergsteen (in original German) and "Projektmanager", published by the German Society for Project Management. Two thoughts:

1. The RUP Book got to chapter 3 before it even mentioned people. Then it spent the rest of the book telling "Workers" how to do their jobs in very minute detail. (And yes, even within the iterations, the waterfall lives.)
2. I looked for the word "Responsibility" (Verwantwortung) in the index of both books. I didn't find it.

I just gave a presentation on Scrum to a group of potential customers in the public sector, one of whom believed quite strongly that good people make good product managers, regardless of the methodology. He's absolutely right on one point. People make projects succeed, not methodologies. And a bad project leader can screw up a project under any methodology.

But Scrum emphasizes people and their responsibilities & committments to each other. It doesn't tell them what to do, but ensures procedurally that if everyone plays by the rules, all the necessary information will become available as quickly as possible so people can do their jobs optimally.

I am now a much better project leader thanks to Scrum. Scrum helped me discover my capabilities.

So I believe methodology and frameworks do make a difference and that Scrum brings out the best in the people on the project.

Update: May 28:

Some futher thoughts on the differences between Scrum and RUP, check out Rational Scrum. I am starting to think that the combination of Lean, Scrum and XP offers the top to bottom framework analagous to RUP, but in an agile context.

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just as the distance to the train station does not depend on whether the traveler walks, runs, rides or drives to the station.

A story point is to program code what a kilogram is to sand or a kilometer is to distance: An arbitrary unit of measure which describes how heavy, far, big or complex something is.

So if we want to answer how long will it take to develop a particular software, we add up the story points, divide by the velocity, and that gives us the time. Think of moving sand: 100 kg / 10 kg per hour = 10 hours. 100 SP / 10 SP per Sprint = 10 Sprints. But how big is a story point? And how do I know what the velocity is?

If we're measuring sand, it's easy to define a reference kilogram. With program code, it's more difficult. Once I played with the idea of converting lines of code into grams, 1000 lines of code = 16 A4 pages = 100g of good paper, but that's just silly, isn't it?

So how do we come up with our reference story point? And how do we know what velocity is?
Under Scrum, estimates are done by the team (if possible, the whole team) who will actually perform the work. So the team defines what a story point is. The classical approach is to look at list of backlog entries, take what appears to be the easiest, and declare that is a 2. Everything else is estimated relative to that task.

The thing to realize about about estimates is that they are very imprecise. +/- 50%. One technique for dealing with a cost ceiling is to define an estimate such that the actual effort needed will be <= the estimate in 90% of the cases, regardless of whether they are measured in days, hours or point.

So Story Points are usually estimated on the Cohn Scale (named for Mike Cohn, who popularized the concept): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Why is there no 4? Well a 3 is a 3 +/- 50%, so a three actually extends from 2 to 5, a 5 from 3 to 8, etc. The difference between 3 and 4 is nowhere near as significant and between 1 and 2, so we don't give estimates that give us a false sense of precision.

Summed together, many imprecise estimates give a total that is a remarkably accurate estimate of the work to be performed (the errors tend to cancel each other out, rather than accumulate). For this to work, the backlog entries must be independent of each other. If you estimate tasks that are dependent on each other, then errors accumulate and cascade. (See the update of 27/05/11 below).

Where does velocity come from? Before the first sprint, we guess. In the first sprint, the team accepts work based on gut feeling and discussion. After each Sprint, we measure the velocity. After two or three Sprints, the average measured velocity can be used to predict the velocity in the future, and thereby the completion date. It is also possible to derive values, like $/SP, which can be used to estimate project costs.

Story points are used to estimate items on the product backlog, i.e. items which represent value to the customer. They are not used to estimate effort to produce artificats needed by the team. In Scrum, we track progress based on results delivered, not on effort applied. So use story points to estimate stories in the Product Backlog, not tasks in the Sprint Backlog.

Used this way, the Scrum Release Burn Down Chart provides an accurate picture of the progress of the project, so management can rapidly recognize and react to the project's progress (or lack thereof).

Story Points are not totally uncontroversial, and I'll talk about some of the issues and alternatives to Story Points in a later post.

[Update 31/10/2010: Thanks to Christopher Messina for pointing out some ambiguities in the concluding paragraph, which I have now corrected.]

Update 27/05/2011: I have realized that two kinds of independence are critical for accurate estimates.  Check out this new blog entry - The Key to Good Estimates

Fingerspell Flashcards - Done :-)

Done. This brings me to my own little pet project, the FingerSpell Flashcards.

I have a hobby. Sign Language. There is really no reason for me to have this hobby, but I have long been curious about using signs as a means of communication.

There are a lot of challenges in learning a sign language, one of which is the speed in which native speakers can sign — I suppose that's not that different from a learning a spoken language, actually.

The finger alphabet is not the same thing as the sign language. Sign languages are a much more efficient way of communicating ideas than simply spelling out words. The alphabet is still important and is used mostly for names and places, but also for words that don't have a dedicated or well-known sign.

Not finding a good tool for learning to finger spell, I wrote one. It was a double learning experience: I have gotten much better at finger spelling and I got to cut my teeth on AJAX. After showing it to colleagues in class, I was really motivated by their reactiosn to polish the program and put it on the web or even commercialize it.

So it needed a better visual design. It needed to do address a wider community so it needs to be multilingual, not just the text on the web site, but it needed to support American Sign Language (ASL), French Sign Language (LSF), German and Swiss German Sign Languages (DGS and DSGS). Each has its own alphabet. The list of wonderful features got longer and longer, and it seemed like the program would never be finished.

And then came jp's email. Eureka! Focus on getting it done!

This 'done' means more than just getting the features done. Done means the product is out there producing a return on investment. And there were plenty of cool new features to implement. So getting to done meant shortening the list.

So I thought - prioritize. What does it need to be releasable, what can be postponed to a later release? Here is the list I came up with:

Version 1.0

1. A user can choose between ASL und DSGS signing languages
   
2. An ASL user can display words from a database of US names and places
   
3. An DSGS user can display words from a database of Swiss names and places
   
4. A user sees the pretty new pictures Hans Peter, Norbert and I created
   
5. *A user understands the licensing conditions (Creative Commons)
   
6. *A user who appreciates the service can make a paypal contribution
   
7. *A user can enter a word to be fingerspelled from the keyboards
   
8. *A Windows User can see the screen properly with Internet Explorer
   

The first three points have been working for a while, the rest, those with a '*', while not a lot of work, needed be done, and with this feature set, I would be willing to tell the world about it.

Version 1.1:

• A user can use the site in German
  
• A user can use the DGS Alphabet
  
• A DGS user can display words from a database of German names and places.
  

Version 1.2:

• A user can use the LSF Alphabet
  
• A LSF user can display words from a database of French names and places.
  

Version 1.x:

• User contributions go to a new paypal account
  

So I was able to push a lot of work into the future and today, version 1.0 is done. Thanks to the joys of Internet Explorer, I am not sure if got all rendering issues fixed (css patches would be most welcome), but it's working well enough, that the time has come to set it free.

So where's the ROI on a project like this? Well, mostly this is about the satisfaction of having a cool tool out there, learning some interesting things along the way, and hopefully helping a lot of people learn to sign. I have no idea whether the donation model is a viable way of financing software, but shareware has a long established tradition, so we'll see. But if it weren't out there, I'd never find out.

So here goes! Version 1.0 is officially live.

---

---

It's Done! (or is it?)

A few weeks ago, jp pointed me to an interesting article about the various levels of done:

"A feature is not "done" until all of the following can be said about it:

1. "All unit tests are green.
   
2. The code is as simple as it can be.
   
3. It communicates clearly.
   
4. It compiles in the automated build from a clean checkout.
   
5. It has passed unit, functional, integration, stress, longevity, load, and resilience testing.
   
6. The customer has accepted the feature.
   
7. It is included in a release that has been branched in version control.
   
8. The feature's impact on capacity is well-understood.
   
9. Deployment instructions for the release are defined and do not include a 'point of no return'.
   
10. Rollback instructions for the release are defined and tested.
    
11. It has been deployed and verified.
    
12. It is generating revenue.
    

"Until all of these are true, the feature is just unfinished inventory."

At one level, the definition of done is one of the key parameters in the Sprint contract between Product Owner and Team. It contains procedural points which every team member much achieve before his tasks or stories can be checked off as done. The list should be long enough (or thorough enough) to assure the desired level of quality and yet short enough and concrete enough, that the points can actually be accomplished.

At a project level, getting to done means actually getting a return on the investment in software. Any software which is not generating an ROI is inventory sitting the warehouse, costing money, losing value and otherwise doing nothing useful. This aspect of done is the responsibility of the Product Owner, not the development team.

And getting a product done means more than just getting the features done. Done means the product is out there producing a return on investment. And there are always cool new features to implement.

In the last year, I have been involved in two major projects which have come in on time and on budget. Both were managed using Scrum and had a Product Owner who had his eye on the ball, who was focused on getting the project out the door. A third major project (which wasn't using Scrum and which I am now trying to bring order to) doesn't seem to have had anyone focussed on getting the product out the door. And it shows.

One secret of successful projects: a product owner who is genuinely focused on getting a ROI from his project. It's not the only key ingredient, but without it, the project will go nowhere.

[Update: Check out the Lean Definition of Done]

Scrum Breakfast in Zürich: March 5, 2008

The next Scrum Breakfast in Zurich is dedicated once again to a report on practical experience. We are fortunate to welcome one of the most experience Scrum Masters in Switzerland, Jiri Lundak, who will talk about

Scrum in the Public Sector: Practical Experiences

Two months ago a 4 year project development project came to a conclusion. Along the way, it transitioned from being a traditionally managed project to being a Scrum Project. His talk emphasizes the problems (and also the successes) of using Scrum in public sector projects.

Topics:

• Hurdles a software company faces, when it decides to become agile
  
• The challenge of staying agile
• Lesson learned
  

Bio:

Jiri is the head of Software Development at Löwenfels Partner AG in Luzern. The company is specialized in developing software for the Swiss social security agencies.

With over 20 years of experience as a software engineer, architect, team leader and project leader, he has been working with agile software development since more than 9 years, emphasizing XP and Scrum. He became the second Scrum Master in Switzerland in 2004. Today he is working on transmitting his experiences in conferences, training courses and other event. He is working on a book, "Agile Processes - Recognizing and Avoiding Traps".

Date: 5 March 2008 (always the first Wednesday of the Month)
Time: Doors open at 8.00am, conclusion 10.00am.
The talk starts at 8.35 (so that you can come by train at 8.30 and still be on time).
Location: namics ag, Konradstrasse 12, CH-8005 Zürich

The talk will be held in German.

Attendance is free and, as always, namics is sponsoring the coffee, gipfeli (croissants) and orange juice. To register, just send me a private message or better register on xing.

Scrum Breakfast in Zürich: Continuous Improvement

Yesterday, Marcello Leonardi gave a talk about his experience as developer and Scrummaster in namics' WLC project. It was cool — 25 people, mostly experienced project managers. Some had just started with Scrum, a few had been using Scrum for awhile, and others were just thinking about starting. But all had interesting experiences to share.

Marcello talked about the WLC project. Marcello started as a developer about the time I took over the project, and took over as Scrummaster after about 8 months. On the one hand, I felt like a proud father, because I introduced Scrum to the project and after 22 Sprints, 3 major releases, and a Best of Swiss Web award, the project is still going strong.

On the other hand, after hearing Marcello's talk, I realized that the project is doing better now than when I ran it. Had I made wrong decisions? Left out something important? Could I have done a better job? Saturday, I wrote "Why would anybody want to be [confronted with their own weaknesses and shortcomings]?" And here I am, not 4 days later, confronted with my own words.

Marcello took over the project from me and continued to improve it. Here is a list of the changes he made:

• Customer provided a full time Product Owner
  
• "Customer Day" Product owner on site to work with team
  
• More thorough technical preparation of stories before Sprint Planing Meeting
  
• Introduced Planning Poker to the Estimation Meetings
  
• Added variety in methodology of the retrospective meetings
  

The success of the first two points were made clear when he showed a picture of the team. For the first time in the history of the project, the product owner (customer) was in the pictures. The borders between supplier and the customer were dissolving for the benefit of the project and the customer. Lean Software Development is not just a buzzword, it's real!

This is exactly what continuous improvement means. What you do right should be ritualized. Everything else can be improved, and improvement is a step by step process.

Congratulations, Marcello! Some day, you'll have a successor. May he or she improve the project, just as much you did!

---

8 Feb 08: Update Marcello's Presentation is now online.

---

Why Settle on Scrum?

Just found this article about Scrum at Yahoo. Gabrielle Benefield, Yahoo's top coach in Agile practices describes the process, and how it speeds up Web application delivery:

Q: Why settle on Scrum?

Gabrielle Benefield: Scrum is great etiquette for an organization. What happens is that if you want something that's very lightweight that can make a huge impact quickly, and be really simple to implement in its simplest form, Scrum is the way to go. It's really successful when you add on the engineering practices, things like some of the extreme programming techniques where they do a lot of testing, where you continuously build your software--things that improve the quality a lot. So Scrum tends to focus on a lot of collaboration, getting the team working, getting prioritization clearly defined, and then you add the engineering practices. And there are things called Lean that came out of the local processes from companies like Toyota, when they manufacture cars--ways of ridding waste through an organization, looking at [ways of] developing things called "just in time." So a lot of these influences are very strong in the Agile community

Read the whole aritcle from Campus Online: Lessons from a Yahoo Scrum Rollout

P.S. But will it save them from Microsoft?

Saving Projects in Crisis

Why does a company (or a team) decide to use Scrum? Adopting Scrum means implementing change, and fairly substantial changes to boot. It brings bad news to the surface and forces management, the team and everyone else to confront their own weaknesses and shortcomings on a monthly basis. Why would anybody want to do that?

There are obvious symptoms of projects being in trouble: Missed Deadlines, Cost Overruns, You haven't had a release in a year. Management or the customer is losing confidence in the project. Staff turnover. Threats and ultimatums. Escalations up the management chain. All are sure signs that things are not right.

But there are also subtler warning signs: "I have been asking for that feature for months!" "We need exact specifications." The project leader curses when her cell phone rings. These are early signs that communication is breaking down and worse problems could follow.

You adopt Scrum because you want a genuine improvement and you know that you need to change. If you are happy with the status quo, you don't need to change, and you don't need Scrum. But if your software development projects are in trouble, and (even your own) success is on the line, then you will be willing to make the commitment to Scrum.

How to make change happen - Bulldozers

When I took over the WLC project, the relations between customer and supplier were very strained (to put it diplomatically). The customer had banned my predecessor from the project. (I'll explain about "letter bombs" in another post. Then again, maybe not). My approach was "there is a new sheriff in town." Here are the rules, Play by them! jp noted that there was a certain irony in the this approach. After telling the team "As of today, you are going to be self organizing", can I really expect them to simply say "yes sir!"?

Blaise Rey of Wibas calls this "the bulldozer approach" and managers who implement change this way "bulldozers". Apply the change. Get an improvement. Don't worry about collateral damage (political resistance). And don't worry about whether the change is sustainable, either.

In this case, the bulldozer or sheriff approach did cause some issues with customer. He felt that his wishes & requirements had not been heard. Now he was being restricted by the rules of Scrum to only being able to tell the team what to do once a sprint. And in the sprint planning meetings, there were time boxes, so the Scrummaster kept cutting him off. He felt like he wasn't allowed to talk!

For this project under these circumstances, I still think the bulldozer approach was the right way to go — we could have discussed for months whether to try Scrum or not. The customer needed to see firm leadership and quick results.

But before moving forward, the team's consent was essential. Without it, the project would have gone nowhere.

After 2 or 3 Sprints, the advantages of Scrum became clear — deliveries on time, better quality, better control — so the conflict evaporated and the collaboration became much easier. The customer quickly realized that he had much more control than before, that he was being heard, and this made him much happier.

Important learning: Emotional Problems in a project are often the result of factual issues which haven't been dealt with. When the factual issue is resolved, the emotional issues resolve themselves as well.

How to make change happen - Coaches

When implementing organizational change, the collateral damage caused by the bulldozer — political resistance — is often the seed of its own failure. A gentler approach is essential.

Just about a year after the WLC project, I was asked to help another floundering project. I felt that Scrum would help this project too, but the circumstances prevented a major disturbance in the workflow. So I built on the team's know how and the Scrum processes to determine the way forward.

We started at the end. The "end" of the Scrum process is the Sprint Retrospective. Well, actually a loop has no end, but the Retrospective connects the functional review of the previous Sprint with the planning step of the next Sprint. The Retrospective is a workshop which follows a simple structure:

• Facts - what happened? Each Team members tells about the high and low points of the Sprint
  
• Positive - what aspects worked well
  
• Improvement - what could be done to improve the project
  
• Control - who has the authority to make each improvement (inside/outside team)
  
• Prioritize - what are the top priorities
  

The retrospective gives everyone a chance to talk about what happened. Everyone identifies room for improvement. Nobody is given the opportunity to just whine. The most important improvements are prioritized first.

The obvious result is two lists, one for the team, one for the Scrummaster (who deals with the rest of the organization). The less obvious result is agreement among all the parties on what to do next. So we start by building a consensus on how to move forward. And this consensus usually identifies things that we can fix using Scrum, so the foundation has been laid for genuine change and improvement.

I call this the "coach" approach. Build the team. Get them committed to the goals. Move forward as team. This is foundation of success.