Agile 101

Project Management, Digital Publishing and Agile Software Development

Posts Tagged ‘Agile Estimation’

Sprint Planning: Hours or Story Points (?) – that is the question!

Posted by Tara Hamilton-Whitaker on August 24, 2009

There is a lot of debate about whether to estimate sprint requirements in hours or to leave them in Story Points.

Mike Cohn is big on breaking User Stories down into tasks, which are then estimated in hours.  Mike discusses this in his post: Why I don’t use story points for sprint planning.

Jeff Sutherland claims that “the best teams [he works] with burn down story points. They only burn down when a story is done.

Personally, I see pros and cons of both approaches but would use Story Points over hours where/whenever possible.

Mike Cohn claims that he doesn’t use story points for sprint planning because “story points are a useful long-term measure. They are not useful in the short-term.”

I don’t agree with this statement as a whole.  Story Points are indeed a useful long-term measure, however I believe they can also be useful in the short-term.

When writing user stories, you should aim for each story to comply with the ‘INVEST’ acronym – Independent, Negotiable, Valuable, Estimatable, Small and Testable

If each story is Small enough to be ‘accurately’ estimated, and Testable enough for one to create Test Confirmations then there may be little benefit achieved through breaking it down into smaller composite parts or re-estimating them in hours.

In fact, back in the days when we were ‘Doing Agile’, one of our teams used to create task cards with the words “just do it” written on them…  In this particular situation, the team were not benefiting from the time spent re-writing task cards and re-estimating the stories – each story was taking no longer than 1-2 days to complete.

The main concerns I had when we initially discussed the idea of burning down in hours was that we’d not benefit from the early warning signs provided by the burndown and that we would only discover a story was taking longer than expected when it was too late.

The reality of the situation is that the team soon discovered their ‘Agile Heartbeat’ – in order to stay ‘on track’, they need to burn down +/- one story per day. Also, the team members generally know when something is taking longer than expected – their communication is strong and they raise any concerns at the Daily Scrum

With that said, if the team is less established, AND/OR if the stories are much larger AND/OR if the sprint duration is +/- 1 week or less then I’d be inclined to estimate in hours as they have the potential to provide a more granular progress snapshot.

Mike Cohn suggests:

It would be appropriate for a team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we will finish in the next sprint.”

I do agree with this point, in the sense that nothing is definite– you can’t be 100% certain that you’ll finish everything you commit to.

With that said if a team has a velocity of 20 story points, aren’t they likely to commit to delivering +/-20 story points worth of stories in the next sprint? AND if they are true to their velocity, then surely they’ll deliver them – will they not?

On the other hand, it is still important for the team to be comfortable and confident that they can deliver their commitments – if they only accept 15 points one sprint then so be it.  This discussion is about whether or not you can achieve the same end result burning down on story points vs. hours – I think you can.

What do you think? Hours or Story Points?

Read more about Agile Estimation

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Advertisements

Posted in Agile Estimation | Tagged: , , , | 10 Comments »

Agile Estimation and the Cone of Uncertainty

Posted by Tara Hamilton-Whitaker on August 18, 2009

The Cone of Uncertainty is a Project Management term used to describe the level of uncertainty existing at different stages of a project.

In short, we become more certain of our estimates as we learn more about what we’re estimating.

In Agile Project Management environments, we accept that software projects are ridden with uncertainty – it comes with the territory. This uncertainty decreases as decisions are made around scope and approach – the more we understand, the more certain we can be about our estimates.

To mitigate the risk of incorrect effort estimations we reduce the precision of our estimates according to how much we know about what we’re estimating. This in turn helps us to be more accurate.

(See: Software Estimation: The more precise you are, the less accurate you will be).

Agile Requirements in order of Uncertainty

  1. Agile Theme
  2. Agile Epic
  3. Agile User Story
  4. Agile Task

(See: The Difference Between Agile Themes, Epics and User Stories)

Agile Estimation Techniques in order of Precision

  1. Hours
  2. Story Points
  3. T-shirt Sizing

Estimating in Hours vs. Fibonacci

As described in my post Software Estimation: The more precise you are, the less accurate you will be, studies suggest that estimates taking place during the Product Definition Phase exist somewhere between being 300% less and 0.75% longer than it actually took them to build the software i.e. out by a factor of x16. The cone of uncertainty narrows as you eliminate uncertainties.

In Agile environments, we use two main estimation metrics – Fibonacci and Hours.

Estimation using hours is pretty self-explanatory, however it’s worth mentioning that Agile Teams only estimate Tasks in hours.  By Tasks, I mean ‘parts of a User Story’…something very small that should take a couple of hours or so – definitely no longer than a single day to complete.

Why?

Because larger pieces of work are generally more complex and should/could probably be broken down into smaller component parts AKA there may still be a number of outstanding decisions that could affect the level of effort required to deliver the task.

The larger the task, the lower the chances that you’ll be able to estimate the exact number of minutes/hours associated with delivering it e.g. Phone interruptions, toilet breaks, delayed meetings.

In other words estimate SMALL things in hours.

Estimating in Fibonacci is the second Agile estimation metric – we call this Story Point Estimation.  We use Story Points to estimate larger pieces of work i.e.  User Stories and Epics.

They work as follows:

0,1,2,3,5,8,13,21,34,55,89

In other words, a ‘5’ is 5x more effort than a ‘1’ and an ‘8’ is 8x more effort than a ‘1’.

Story Points can measure things we can’t measure in hours – e.g. complexity – do you include a task for every discussion you don’t yet know you need to have, every time you take 10 minutes out to Google an answer? It is however relatively easy (when you get started) to compare the size of one task/cluster of tasks with another task/cluster of tasks.  Estimating in Story Points allows you to take into consideration all sorts of intangible ‘things’ that you sense but can’t quite put your finger on.

(See: Software Estimation: The more precise you are, the less accurate you will be)

Estimation Using T-Shirt Sizes

T-shirt Sizing is an Agile Estimation method – it’s used to estimate larger requirements i.e. Epics, but maybe the odd User Story also.

In short, you attribute a number of story points to a t-shirt size e.g. an XXL might equal ’55 points’ as shown in the diagram below. T-shirt sizes are great for Product Owners and/or non-technical people as they’re totally abstract and non-threatening (that’s not meant to sound patronising…you know what I mean!). They’re easy to understand.

When estimating in T-shirt sizes, it’s still important to set your scale – agree in advance what constitutes a ‘Small’, ‘Large’ and ‘XX Large’.

T-shirt sizing will normally take place at the Requirements Workshop – this helps the Product Owner and Product Manager get a sense of scale, which will in turn help with the prioritisation process.

As always, the Scrum Team are the people that assign t-shirt sizes to Epics.  The Product Owner and/or Product Manager are not allowed to participate in the estimation process – they can offer insight and guidance but the estimations belong to the Scrum Team.

Estimation Using Story Points

Once the Epics have been estimated and prioritised for delivery, they will be broken down into User Stories by the Product Manager and Product Owner.

The component User Stories will then be introduced at a subsequent requirements workshop and estimated in Story Points at Poker Planning.

(See: Scrum Sprint Planning Meetings: Who, What, When, Where, Why)

Read more about Agile Estimation

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Posted in Agile Estimation, Themes, Stories, Epics | Tagged: , , , , , , | 3 Comments »

Self-Funding Projects – A Benefit of Agile Software Development

Posted by Tara Hamilton-Whitaker on July 22, 2009

self-funding-project-chartOne of the many benefits of developing software in an iterative way is that you can start realising the benefit of your work before the project is officially ‘finished’.

The objective is to front-load the project with the most profitable or highest value deliverables and release them as soon as possible so that they can start making money for you. If you’re using a Lean approach, you’ll release them as soon as they’re finished, if you’re using a Scrum approach, you’ll cluster a few into one (or more) releases at the end of each iteration.

It’s worth noting that not all projects or deliverables offer a financial return, however one assumes they still offer value of some sort e.g. Strategic, Compliance, Risk Management, Cost Avoidance, Technical Debt etc. These types of projects/deliverables may never become self-funding.

Those projects that do offer a financial return and particularly those that have been pitched for off the back of an impressive Return on Investment model should become self-funding at some point during the project lifecycle.

Self-funding projects are great for the following reasons:

  • Less investment required up front
  • Less debt being carried through the project
  • Reduced risk

I will share a scenario in hopes to illustrate this concept more effectively.

For more details on the scenario itself and what to do when assessing your own project, download the Excel Template at the bottom of the page.

Self-Funding Projects - A Benefit of Agile Development

Self-Funding Projects - A Benefit of Agile Development

This scenario describes a project with 25 User Stories of varying size and value.

The team has a velocity of 21 points and for the sake of simplicity, a cost per sprint of £21 i.e. £1 Cost Per Point (“CPP”).

I have included a financial cost (CPP x Story Points) and an ROI for each User Story.

In reality, it is unlikely that you would/should take the time out to calculate the ROI for each story, however it helps to illustrate this point.

With that said, you may choose to produce an ROI at an Epic or Theme level, then prioritise the comprising stories using Value Points vs. Story Points.

As a starting point, calculate the earning potential of each story i.e.

Revenue – Cost = Priority

For non-financial scenarios, you could calculate Priority using the following equation:

Value Points – Story Points = Priority

After determining the priority of each story, you can produce a release plan.  Take care to squeeze as much value into each sprint as possible – this may mean you need to de-prioritise certain high effort / high return stories  in favour of a low(er) effort task so as to stay within the Velocity.

Some factors to consider when prioritising delivery include:

  • Story Point (Effort)
  • Value Points
  • Velocity – You may need to prioritise low effort/low(er) return stories over higher effort/return due to capacity
  • Risk
  • Other: e.g. dependencies, constraints, holidays, skills e.g. Do you have the skills required to deliver the story?

As you would expect, the percentage return for my fixed £21 per sprint effort is much higher towards the beginning of the project.

For example:

Sprint 1: Cost = £21, ROI = £165, 686% return

Sprint 2: Cost = £21, ROI = £89, 324% return

Sprint 5+: The ROI doesn’t justify the Investment. These stories should be dropped unless they deliver a high value, non-financial return.

The total cost of the above project is £122 with an ROI of £383, however from the end of Sprint 1, we are £144 in profit with only £101 of outstanding cost. It is at this point that the project becomes self-funding i.e. the generated profits can sustain the rest of the development.

In theory, we *should* be able to deliver this £122 project with an investment of only £21 up front, a rather attractive prospect to any investor.

In a traditional waterfall projects, we’d require the full £122 initial investment and would realise no return until after the project was finished. This leads to :

  • Higher cost
  • Higher risk
  • Higher levels of uncertainty

There you go – the rationale behind self-funding projects in a (highly simplified) nutshell.

download

Case Study: Self-funding Projects - A Benefit of Agile Software Development

 Related Articles:

Posted in Agile & Scrum Templates, Programme Management, Project Management | Tagged: , , , , , | 2 Comments »