Story Points to Ideal Days

Question

History

I work within a IT Team for my business that delivers (Develops & Unit Tests, QA, UAT and Releases) either system improvements or new systems to different areas of our business.

The team I work for have implemented various areas of the Scrum Framework over the last couple of years:

1. Roles: Product Owners, Scrum Master and Scrum Team
2. Artifacts: Product Backlog, Burndown Chart
3. Ceremonies: Daily Standups, Sprint Planning and Sprint Retrospectives

The Product Backlog is made-up of work that estimated using a Plan Driven system, whereby work is authorized. This is because we are one of many different teams within IT (Operations, Infrastructure etc) that don't use Scrum/Agile/Lean Frameworks and reply on this Plan Driven system to have System Change authorized. This system, explained is:

1. Our Super Users log a change request.
2. We run a requirements workshop to get a "sense" of how big the job is.
3. The change request is then assigned to our 1st authorization stage which is made up of business/IT staff who either authorize it or reject it.
4. It is then assigned to us to quote. We have to quote based on hours which translate into pounds it will cost them.
5. The change request is then assigned back to the business to either authorize or reject the quote.
6. If the quote is authorized, then the change request is assigned to another committee to say "yes" or "no" based on current IT priorites

So as you can see, alot of committe's and upfront design before we even get for us to add the item to our Product Backlog.

My Question (Finally!)

I want to introduce better estimating and more efficient requirements capturing, which should lead to better PLanning. Now i wanted to use Planning Poker, User Stories and Story Points with a proper Sprint Board and to capture the required data (story points) to measure our Velocity. My constraints are they must fit within this Plan Driven system described earlier.

What I'm trying to ask really is can i use Story Points within this system as we need to quote upfront Hours for a Backlog item during the Plan Driven system. Is there a way of using Story Points AND Hours together? Reasons for wanting to use these Scrum parts:

Planning Poker - Improve our group estimation process in the negotiation of better estimates. Trying to reduce the "larger than life" characters from influencing our group estimations.

User Stories- I like the idea of breaking out our Epics into small concrete pieces of work which we can decompose later into tasks. This should help our QA exercise greatly and help us see the forest from the trees in terms of breaking out backlog up into smaller shunks so we can run smaller iterations.

Story Points - This makes sense to me as a good way of measuring our velocity without using Ideal Days and getting bogged down with thinking about time when measuring effort for stories.

Answer 1

TL; DR

Story points measure effort; hours measure time. They are not interchangeable. You're going to be better off estimating man-hours, ideal hours, or calendar days from the beginning.

Scrum may not be the right fit for you, either. Kanban or Lean might be a better approach given your IT Governance constraints.

Story Points Don't Fit Your Organization

Your organizational process is a poor fit for story points. You aren't allowed to use relative measures for planning, so story points are not going to be a useful tool. While user stories may remain a useful tool for capturing requirements at a high level, the necessity of estimating in hours and pounds may mean that you will actually need a finer-grained work breakdown structure (WBS) than user stories are intended to provide by themselves.

An Alternative Estimation Approach

All this is to say that you should strongly consider something more like the following:

1. Define a change as a user story to capture the high-level requirement.
2. Break the story down into tasks, with an associated time-based estimate for each task. Whether to use ideal hours, calendar days, or some other time metric is entirely up to you; some experimentation may be in order.
3. Submit the WBS and the time-based estimate through your change control process.

Even in Scrum, stories are eventually broken down into tasks that are (usually) 4-16 wall-clock hours each. While this granularity can vary, it is part of the control mechanism for determining slippage within a sprint. Since stories are either "done" or "not done," each task needs a time-box, and 1/2 day to 2 days is generally a manageable size for such boxes. Your mileage may vary, but it's a decent starting point.

Scrum May Not Fit Your Organization

Your "Product Backlog" is really an internally-driven Change Request Log, with outside approval of the estimates. While Scrum certainly provides for input from the team through the Product Owner to the Product Backlog, the process you describe is entirely upside-down from a Scrum perspective.

Whether or not you're using story points, it actually sounds like your particular organization would benefit more from a different project management framework. While you may still be able to use time boxes to manage your WBS, I don't think Scrum as a process framework fits the way your organization does its planning or controls deviations from schedule. Of necessity, you will find yourself mapping internal processes to external IT Governance with such regularity that it may not necessarily buy you anything to use a different framework internally.

As an alternative, Kanban might offer you an internal process for managing work with a reliable cadence that isn't based on time boxing. In my opinion, Kanban offers a framework that fits better when work is on-going or demand-driven, and has a tighter focus on team cadence than on time-boxing. You'll still have to remap your process when interacting with your IT Governance framework, but it may be a more sustainable internal process for you than Scrum.

I'm not necessarily suggesting that you drop Scrum, adopt Kanban, or switch to waterfall. I'm really just suggesting that you take a long, hard look at your project management process, and decide if it's really working for you. If not, find an alternative that fits better!

Answer 2

There is always a temptation to map story points to hours (or ultimately days). I would recommend that you avoid that mapping as story points are a relative scale of effort that has nothing to do with hours in your estimation process. For example if you have a baseline story and then all story points are measured against that baseline a storypoint of "2" means that this story is 2x harder than your baseline.

That all said, the best approach is to do an actual sprint and then calculate the team velocity. You can then use actual data and measurements (story points left, average story points added after each sprint, actual team velocity) to calculate the "estimated sprints to completion". If you do 2 week sprints and then your estimated sprints to completion is 10, then it should take you 20 weeks for the project to get done. After about 3-4 sprints, this number gets more and more accurate. I like this method since it gives you the most accurate way to "map" story points to time. The downside is that management usually wants a time estimate up front and in your Plan Driven system you will need to do something else.

Assuming that you have a team velocity already, this is not a problem. At step #4 above, convert the work into the number of sprints (or if the request is small, the percent of a sprint). For example:

Work item estimate: 20 story points Team Velocity: 100 Sprint time: 2 weeks Cost for sprint: $10,000 Cost for the 20 story points: $2,000

This is not a perfect system, but it should work. :)

Lastly, have a look at Kanban since the Plan Driven system you describe would work well with it.

Hope this helps.

Answer 3

I would avoid at all costs mapping points to hours.

I've tackled this previously by using a session similar to your early requirements workshop to break the work up into reasonably large epics (usually workflow steps from a customer perspective).

We'll then estimate those chunks in weeks of effort giving a ranged estimate and noting any assumptions we're making. Where the range given by the team is large we'll drill further into risks to try and uncover where the uncertainty lies.

The total range as well as the assumptions and risks can then be presented back to the committee. If there is too much uncertainty (the range is too big) for them to commit to the project, you can then ask for time to investigate some of the risks and assumptions to see if you can get some more certainty.

This lets you get an up front cost estimate and makes it really clear to all involved what (foreseeable) things will affect that cost without going to the level of creating all your stories up front or having to convert from points to hours.

Here is the output of similar sessions my team did a while ago:

Finally, you might want to see how amenable the committee would be to changing the process slightly. We now ask the people who sign off budget for work to tell us, based on the expected benefits of the work, what the maximum they would be willing to invest would be.

The tech team can then look at the work and decide whether we'd be able to meet the core requirements with that investment. This type of benefits led sign off feels more healthy to me as it avoids fixing the scope up front, and helps focus everyone on the final objective rather than the detail.

Answer 4

No answer just a tip. Keep track of these stories and the time spent analyzing, refining, estimating and debating them. Count the committees as well. Then post how many hours are lost on stories which were, at the end, not going to be built. There's easy savings for your organization.