Skip to main content

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...

Comments

Anonymous said…
Hi, Thanks for your post. I have one question. Consider there 2 identical stories in the backlog. One taken at the sprint1 and anotehr one is planned only for spirnt 5. During spirnt 1 the team has sized Story A as "M" and when we went to Sprint 5 the sized the Story B as "M" again bec the previous story was sized as "M".

My quesiton is

1. Do we have to consider that the similar story was implemented earlier and so duplicating the story might be easy and so size should be less

2. Or do we have to size the new story as "M" and take additional story if the team has time to work on more story..

i asked this qustion bec the customer is insisting us to reduce the size of the story because they think it is easy to implement this story bec similar story already exists

I need your advince in this'
Anonymous said…
Hi, Thanks for your post. I have one question. Consider there 2 identical stories in the backlog. One taken at the sprint1 and anotehr one is planned only for spirnt 5. During spirnt 1 the team has sized Story A as "M" and when we went to Sprint 5 the sized the Story B as "M" again bec the previous story was sized as "M".

My quesiton is

1. Do we have to consider that the similar story was implemented earlier and so duplicating the story might be easy and so size should be less

2. Or do we have to size the new story as "M" and take additional story if the team has time to work on more story..

i asked this qustion bec the customer is insisting us to reduce the size of the story because they think it is easy to implement this story bec similar story already exists

I need your advince in this'
Peter said…
Dear Anonymous,

Thanks for your question! Questions like this are easier to answer if we ask ourselves, why are we making an estimate. I think there are three good (and many bad) reasons for estimating. The good ones:

Build a common understanding of the story -- This helps everybody get the implementation right.

Get an idea how expensive a story will be to implement -- this helps the Product Owner decide whether and when to prioritize the story.

Ensure that your wishes are more or less in sync with reality -- this enables to Product Owner to set realistic expectations with other stakeholders.

Among the bad reasons: giving the PO and Dev-Team ammunition to fight with.

My first piece of advice: It's only an estimate. Don't spend more time on the estimate than necessary, because estimates have no value for your users. Fundamentally it's an artifact of the development process, not a deliverable.

What speaks for changing the estimate: If you expect the feature will be much cheaper or much more expensive to implement than you originally anticipated, sharing that with the Product Owner will help him/her make better decisions.

What speaks against changing the estimate: Time spent on estimating is fundamentally wasted time. Changing the estimate of a story individual story also changes the estimate of the remaining features to release (burn-down target moves closer or further away). Estimate changes look like changes in scope, so this makes it much more difficult to figure out when you actually expect to release and it is less clear whether your backlog is changing because of changing estimates or scope creep.

So my personal inclination is not to worry about changing the estimate (unless there has been a substantial change in the acceptance criteria or understanding of the story). The difference between a 5 and 3 on 100 or 200 point project is just not worth wasting time on. Your velocity will be a little bit different in that sprint. So what?

OTOH - if your PO wants it and it's important to her/him, go with the flow. It's just an estimate. So pick a pragmatic approach that works for you and your Scrum Team and go with it.

Cheers,
Peter

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …