#agile2011 Monday night thought – Does using only #Velocity limit the opportunities for #acceleration?

I just finished reading an excellent Blog entry on transitioning from traditional estimating to Story Point estimating by Ilan Goldstein. You can find the blog post at the following link:


The article walks through the estimation process used during the transition there are three excellent points.

1. I loved the idea about being above-board and listing the conversion table between Story Points and the range of hours typically associated with those Story Points. Let’s face it, everyone is doing the mental math and the only thing worse than people doing the calculation, is everyone using a different version of the table in their own head to do the calculation. So let’s all just agree what that conversion table is. Excellent.

2. Taking previous features developed and incorporating the effort they took into the estimation process is wonderful. I have not heard mention often enough about tracking and comparing estimates versus actuals on User Stories so that our estimating get better each Iteration. This process of creating reference User Stories in points by converting the hours they actually took helps to leverage the previous project work to make the estimating of future work as accurate as possible. Brilliant. The additional step to then throw away the hours per feature and use on the Story Points going forward is ideal.

3. The point to then track both the time completed and the time remaining on active User Stories ensures that we are continuing to learn and get better with our estimating as the project proceeds.

I think these three points just add the value of planning poker and makes the entire estimation process the best it can possibly be.

Why do I like these ideas and processes so much and what does that have to do with the title of this Blog?

It has always been a personal belief of mine that setting completion expectations for a project team with only a collective measure (velocity) for the entire iteration is not optimal. Using relative estimating to produce accurate estimates and using velocity to plan for the average progress of a project is fine, but even Mike Cohn stated he does not recommend using Story Points for Sprint Planning.


Mike Cohn mentions that velocity is not a useful short-term predictor and I agree. I would also add that not only is it not a useful short-term predictor, but also can possibly not set the proper short-term expectations for User Story completion times. When used, Story Points by their nature allow for a separation from day-to-day complexities that can cause inaccurate estimates. When used, Story Points by their nature can also allow for a separation from day-to-day expectations. For example:

  • How long should a 1,3,5, or 8 point story take?
  • Do we need to wait until the end of an iteration to react to a story that is taking longer than thought?
  • Would knowing that a story should take 2 days on average help to alert the developer of potential issues?
  • Would knowing that a story is going to take longer than expected allow for the splitting of a story in the middle of an iteration and the ability to deliver more ‘Done’ work in the iteration?

If I am for the most part only reviewing velocity at the end of the iteration and not at some level on each User Story during the iteration, am I limiting my opportunities for acceleration?  (Acceleration being the rate I can change my velocity.)


Agile Project Planning – 4 lightweight practices

How the heck Do you plan an Agile project?

If you listen to some Agile proponents out there you might think that Agile projects do not have a planning phase. You may have heard the following:

  • You shouldn’t create a plan as things will change and it will be wasted effort.
  • You shouldn’t create estimates as they will just be wrong and it will be wasted effort.
  • You should just start executing iterations and you will then determine your team’s velocity and what you can achieve.
  • You just keep on working on prioritized stories until the client tells you to stop or runs out of money.

As long as we are doing Agile projects we must first remember what a project is. A common definition is:

“a task or planned program of work that requires a large amount of time, effort, and planning to complete”

So really, any work cannot be termed a project without a plan. I would also add one additional criteria to what comprises a project. I believe a project requires two key criteria:

  • A plan that defines scope, cost, and schedule. (At whatever level deemed appropriate)
  • A vision of the solution that defines success for the project sponsor and the project team.

Too often I feel that projects are started without the vision fully crystalized. If there is not a vision of the solution, how can the following be determined?

  • How can the project team be sure the solution truly solves the business problem
  • How can the project team be sure that the solution is functionally and technically cohesive, consistent, and correct
  • How can the project team be sure that the project budget and schedule can deliver a solution that satisfies the minimum client success criteria?

Without taking the time to confirm the vision of the project we are risking the success of the project.

Kan Ban boards are not the Plan

What made me think about this? I have seen more and more Kan Ban boards which people use as the project plan. Kan Ban boards are intended to be visibility into the project plan and status, but should not be the project plan itself. There needs to be a plan outside of the Kan Ban board that defines the project plan with some amount of dependency management. In addition, a separate vision of the solution should also exist. (Both functionally and architecturally)

Without these two artifacts I would suggest that you may not have an actual project and your Kan Ban board may simply be stickies on a wall. 🙂

So how do you plan an Agile project?

Now I am not proposing a detailed work breakdown structure for an Agile project. I believe there are lightweight methods that can provide the value for minimal cost. I typically plan an Agile project in the following 4 ways.

  1. Ensure that Project kick off, Charter, and risk sessions are held. These are very short meetings but start to ensure that all team members share a common understanding of what the project is expected to achieve.
  2. Hold a Rapid Discovery Event to confirm the scope, objectives, and high-level plan of the project. This session should  take only 1-2 weeks for a 3-6 month project. This event is critical to build a common understanding of the vision and solution.
  3. Create and estimate the project schedule at a deliverable-level with dependency management to ensure that the project can deliver the minimum client scope, budget, and schedule requirements
  4. Gain agreement from the client as to how the Agile project will be run and the ‘rules of engagement’. We have already confirmed we think we can deliver the minimum functionality, so this meeting is focused on gaining agreement on the process of how we will work together to deal with change.

I’m not proposing a detailed project plan, requirement document, or architecture document, but a little work on all three can go a long way to ensure success.

Project Estimates versus Targets

I was going to have another Blog post that talked about Agile estimating, but I think a Blog about estimates versus targets should be done first. In short, I think the confusion and mingling of the terms have led to many ‘perceived’ project failures. As usual, let’s start at the start. 🙂


Estimate – An opinion and educated guess as to the amount of work, people, and ultimately duration. An estimate can only considered an estimate if practitioners have created it. Ideally, an estimate is only an estimate if the project team has created it. But it the consulting world, this is sometimes impossible. The most I can hope for is that skilled and competent technical resources have created the estimate, even if they are not going to be on the project team.

Target – A opinion and uneducated guess as to the amount of work, people, and ultimately duration. A target is different from an estimate in that it is usually created by non-Practitioners. The target is usually created to put a stake in the ground to reflect an Enterprise objective or goal, Regulatory requirements or the criteria required so that a business case holds.

The Problem

The problem that I have seen over and over again in the Information Technology industry is the inter-mingling of targets and estimates. Many times we ourselves are the problem. In an effort to be non-confrontational we accept targets as now the project estimate. Subsequently, the corporation wonders why our Software Development projects never meet estimates. In my experience, Software Development teams meet estimates pretty well, where we struggle is meeting targets. Is this any surprise? I’m sure if I created a target for the annual budgeting process for a large corporation I also would be way off because I can’t appreciate all the processes and factors that need to be considered. (Hey, an analogy I can use!) 🙂

I have usually found that even if a project team acquiesces to a target provided/imposed, the project itself usually comes in at about the estimate the project team created. Typically, the project team can estimate accurately unless the project is in a totally new technology or domain.

But what If I am not given a choice?

This is a situation that probably occurs more often that not. I would estimate that most of the times project teams adopt a target as an estimate, they do so because of direction from Senior Management. So what can we do?

I would recommend the following approach:

  1. Education – Start diligent and professional educational communications with Senior Management. Ensure they become aware of the differences between targets and estimates.
  2. Language – Use the language and terminology in all discussions and documentation. This is part of the education plan to communicate the difference between the two terms.
  3. Track both – Even if the project is executing according to an imposed target, track the project actuals against both the target and estimate. Evaluate after the project is complete and build up data from multiple projects. Don’t use this data to support an unprofessional ‘I told you so’ communication. This is very bad form. But this data will be interesting to present in a professional way. Executives don’t like surprises and being called out on the carpet when their initiatives always exceed the plan. Presenting these figures in a professional and respectful manner may convince executives to accept estimates rather than targets. (when possible)
  4. Use estimates internally – Even if targets have been imposed on your team, I would recommend to still create estimates and then use these estimates to track progress with your team. Tracking with targets is unfair to the team. It will create an atmosphere of mistrust and unhappiness. The team will feel that they are constantly failing. The team wants to feel they are doing a good job. Tracking by estimates gives the best opportunity to do that and to measure progress.  Ideally create these estimates with Planning Poker and manage in an Agile way, but that is a topic for another Blog.

Decision Point

These are strategies to move the company and Senior Management in the right direction to have successful projects. It is not a short-term strategy will take multiple projects. If Senior Management chooses to not listen after you have been able to gather the information and present your case, every individual has to decide if the culture of the company is right for them.

But I believe that unless we go through the process to inform Senior Management, we are also part of the problem. The worst thing we can do is just to accept the targets as estimates.

How would you manage a project if it was your money? Agile of course!

This fantastic question was posed to me by a co-worker today. (Thanks Steve!) 🙂 It spurred some great discussion on why Agile project management really does encourage managing the project as if the project budget was your money. Unlike traditional project management, the focus is not just on managing what was agreed to, but rather on managing what provides constant value. To do this, there is focus on managing the two sides of the Value Coin.

The Benefit side of the Value Coin

How many of us would be willing to pay for:

  • Large  documents and deliverables that provide little value to the client
  • Long periods of time with no value to the client
  • Managing to what was agreed to rather than what is required
  • Not being collaborative when new items are found and immediately issuing a change request when something new is discovered?
  • A large amount of risk at the end of the project because we haven’t delivered frequently and iteratively
  • A Manager focusing on reporting rather than ensuring the team is progressing as fast as possible
Agile Project Management does align with how one would manage a project if it was his or her personal money. The focus on constant value is something that ensures the client receives the value they deserve from the project every day.
The Budget Side of the Value Coin
Of course this focus on managing the project if it was your money does have some consequences we haven’t talked about yet. These factors are related to the budget of the Value Coin.
How many of us would be willing to commit to be a client for a project if:
  • We were not given an estimated budget for how much it would cost
  • We did not have confidence in the team and the plan for the project
  • We were not consulted as the project progressed.
  • We were not able to prioritize the work.
Again Agile Project Management allows us to best align with the Budget Side of the Value Coin.
Three Truths
I believe there are three truths to Agile Project Management in light of this:
1) We need to manage projects like the project budget is our money. We need to maximize identification with the client and the benefit of the project. We need to Honestly Care about the client and the value they require every day.
2) We need to provide the client with an estimate for the work so they can make an informed decision. The Benefit side of the Value coin still must be larger than the cost side. We need to be  Fiscally Responsible about what the client is undertaking. We should not recommend a project if we are unsure about whether it can return the required value.
3) We need to ensure that the first two truths do not adversely affect the team. We need to Passionately Support the team by removing issues, obstacles, and problems as soon as possible to deliver maximum value without adding undue team hardship. To often we have seen the team side of the equation be sacrificed as issues are encountered.
I would propose a project can only be successful if all three truths are held.

My Agile Adoption Story

My first experience with an Agile project that was more Agile than Waterfall was in 2006. I phrase it in that way as all projects I have been on have had some aspects of Agile. But I digress, back to the story…

In December of 2005 a fixed price RFP was released for a new Parks Reservation Service that the Government of Manitoba required completion for the spring of 2006. (April 3rd to be exact) We were very diligent in planning to even respond to the RFP as we knew what a challenge the requested time frames would provide. So we met with the proposed team and held a risk session/planning session/estimating session to determine if we felt this was do-able and if we all were comfortable with bidding. It turned out that we thought this was certainly do-able, but it would be a challenge right from the start. We took a vote in that session and it was unanimous that we should bid. We thought that we needed to execute the project in a way that was more Agile than we ever had done before to be successful. This meant to us at the time:

  • Team Chemistry and continuity
  • At least 1 client on site full time with full decision making authority
  • Daily stand-ups
  • Fully empowered team (This is normally the way we operate)
  • Very lean Use Case requirement documents.
  • Demos at least every week to show progress
  • Team Planning and Estimating
  • Visual Project Management
What were we missing?
You may have noticed several current key Agile practices that were not in our list. Such as:
  • Test Automation
  • Continuous Integration
  • Kan Ban
  • User Stories
  • Planning Poker
  • Pair Programming

But before we get to that. Let’s provide some context for the project.

The Problem

  • Dimensions of Parks and Campgrounds
    • 57 Campgrounds
    • About 5,500 campsites
    • 11 Campgrounds currently computerized
  • Requirement was for a Web Application that need to be used by three types of clients:
    • General Public to make reservations over the internet
    • Call Centre employees to make reservations on behalf of campers.
    • Campground attendants to manage inventory, make reservations on behalf of campers, and check-in/check-out campers
  • Web Application needed to have the following main components:
    • Welcome/Login
    • Shopping Cart
    • Campground Management
    • Inventory Management
    • Reservation Search
    • My Account
    • Reports
    • Reservation Maintenance
    • Reports
    • Policy Configuration
    • Integration with online payment provider
Kick off to Deployment in 92 days
To meet the required deadline, we made the following project execution decisions:
  • We partnered with three other companies to provide expertise so we could hit the ground running. (We could have learned this expertise but we did not have the luxury of time to do so)
  • We did not have experience in test automation and felt it would be too risky to learn on this project. To mitigate this we allocated an Application Architect to manually perform Quality Assurance activities daily.
  • We allocated an additional Technical Architect to Performance Test the application for the first three months.
  • We leveraged Protegra Frameworks to speed up development velocity.
  • We had a Technical Spike to validate and confirm what GIS mapping solution we would use.
  • We separated the project into three phases to be able to deliver the functionality when it was required:
    • Phase 1 – Public and Call Centre Focus
      • Functionality focused primarily on the reservation process and reservation maintenance (i.e. making reservations, changes, cancellation, payment, refund, etc.)
    • Phase 2 – Campground focused
      • Focused on management of campgrounds (i.e. check campers in, check campers out, move campers, camping permits, revenue reconciliation, etc.)
    • Phase 3 – Admin site enhancements
      • Focused primarily on providing more back office support to Parks head office users
The Solution
The Solution was a C#, .NET Solution. The database was SQL Server and the architecture was a standard three-tier architecture.
Project Details
  • Project team included over 20 developers at maximum
  • First Phase was delivered in 3 months.
  • Included investigation and integration of GIS mapping technology
  • Phase 1 alone was over 7,400 hours of development work, all three Phases were over 12,000 hours.
  • Quality of the application has exceeded industry standards with only a few defects since go live
The Outcome
The solution was deployed to production on time on April 10th, 2006. For those of you keeping track, this was a week later than initially planned due the time required to train the users. The solution was ready to deploy on April 3rd. This was after the project learned a month before go-live that the code had to be frozen two weeks prior to go live to allow for the acquisition of PCI certification to take on-line payments.
The project was awarded the PMI project of the year (Manitoba Chapter) for 2006.
What We Learned
  • Client decision maker on site is key to a Lean project.
  • Liaise with the clients as much as possible
  • Empowering the development team was crucial.
  • Traceability of requirements is key with formal organizations
  • The team succeeded because they trusted one another
What we would do differently
  • Quality could be further improved with the use of TDD, automated test and build tools
  • Form in sub-teams of 6-8 to maximize efficiency. Assign a Client decision maker to each one of these sub teams.
  • Leverage Visual Project Management to an even greater extent
  • Develop in Iterations, not increments. We really developed fully functioning increments.
  • Use the following Agile practices:
    • Test Automation – We mitigated this risk by assigning one of our top Application Architects, but I would not recommend this approach unless you have no alternative.
    • Continuous Integration – We probably got away with this because we coded in increments. If you are doing iterative development, I believe you need Continuous Integration.
    • Kan Ban – We did not use a traditional Kan Ban board. We now use these on all projects.
    • User Stories – Use Cases were still too large and they were really why we developed in increments. I don’t think you can deliver in Iterations without User Stories.
    • Planning Poker – We had a very senior team who felt very comfortable in a joint planning session and challenging each other’s estimates. I wouldn’t recommend this going forward though as this team was very unique.
    • Pair Programming – Strangely enough, this is one Agile practice that we rarely do. We typically use it more for a mentoring opportunity. The book is still out on this one though as I would like to try it on a project.
Why we succeeded
In some ways we succeeded primarily because of the excellent people and team we had. I believe that is still a key factor in the success of projects. That said, Agile practices do result in better solutions and everyone on the team realizes that we could have had an even better solution and project with them. (And certainly a more stable pace)
I believe we also succeeded because we had the client decision maker on site. This was not just any decision maker though. The Client was a person that had lived and breathed working with the old system, creating the RFP, and knowing what she wanted from a new system. In short, our client on site was also our Product Owner. Very powerful…
Check it out
If you want to check out the solution, you can find it at the following link:

Agile Project Estimate Guarantee

Over the last few days I’ve noticed more discussion around the concepts on whether Agile teams should estimate or not. This includes my latest Blog on the subject:

User Story Points versus User Story Hours

Yesterday I read the following Blog post on the 5 reasons you should stop estimating User Stories:

5 Reasons why you should stop estimating

Given the amount of attention this blog has garnered, I felt I needed to provide an opposing viewpoint. The Blog post was very interesting and compelled me to write as I think these discussion points are missing one crucial factor. To summarize, the blog post proposed that these were the 5 reasons why we should stop estimating User Stories:

1)      Estimating User Stories is a waste and the time can be better spent elsewhere

2)      The estimates will be used for blame and cause the team to focus solely on the deadline

3)      Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.

4)      Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline. (similar to #2)

5)      The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.

What struck me was what was missing from these reasons for not estimating, namely the client. None of the reasons explained why estimating User Stories created less value for the client. And really isn’t that why the project exists?

Estimates, who gets to decide?

The Client does. Sometimes when reading about Agile principles, I fear we are losing that perspective and we are deciding for the client what has value. The reason I believe in Lean so profoundly is that it provides the focus on why we are doing Agile practices. It helps to ensure that we understand the why of what we are doing at all times.

Let’s review the Blog points:

1) Estimating User Stories is a waste and the time can be better spent elsewhere

Whether estimating is a waste is something that only the client can best decide. Estimating is just another project activity that the client will determine if it is required.

So far every client I have worked with have required estimates at some level or another. Whether or not we think the time is best spent elsewhere is immaterial. The client defines value and the value in their value stream. So far, every client I have worked with has found value in estimates as they need to decide whether the initiative satisfies the business case and whether they can acquire the required budget.

2)  The estimates will be used for blame and cause the team to focus solely on the deadline

The fact that estimates can be or may be used for blame is more a comment on a dysfunctional system than a comment on estimates. If estimates can be used in this manner, I would imagine any other deliverable could also be used in this manner. I believe it is the role of a good project leadership team to ensure this doesn’t happen. Not producing estimates is treating a symptom, not the problem.

3) Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.

Estimates are hard, so let’s not do them. They are going to be incorrect anyway. Let’s just wait until they are actuals and then we can report them and we will have eliminated our risk. But whose risk are we referring to? We have just transferred all of the risk from the project team to the client.  If we are professionals in our craft of Software Development, shouldn’t we be able to provide our expert assessment on the situation? If not, why should the client trust us?

4) Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline.

My opinion on this one is similar to #2. This is more a comment on a dysfunctional system than a comment on estimates.  The comment implies that the team will sacrifice quality to meet an estimate.

This sounds like another instance of treating the symptom and not the problem. If a project manager is holding the team to estimates and not engaging the client with new ideas, then the Project Manager is probably not the right fit. If the client is doing this, well that is certainly the client’s call. It is after all their solution. Quality for the client may be meeting the deadline.

5) The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.

Valid point. But I think this is the correct behaviour. Large stories will shift the priorities because of the perceived large risk they entail. This I believe is consistent with the principles of Agile to take on these large tasks early to minimize risk and learn fast/fail fast. I don’t think this is necessarily related to estimating. In fact, this is a reason why we need to do estimates. Estimates will ensure we identify the large epics as high risk items and address them early. This will help us to fail fast. If we do not estimate, we may leave these this stories as a lower priority and they will be done later and possibly cause project rework.

Next Steps

One critical benefit about providing an estimate to the client is that it completes the commitment cycle. Typically clients commit budget and teams commit to an estimated solution vision. This estimated solution vision is at a very high level that identifies the features and interactions between the features. It is not big requirements or design up front. But the team should have an understanding of the solution vision before starting or the potential is that excessive rework may be required after a considerable amount of work has already been completed.

In short, preparing that estimates forces the project team to understand and envision the entire solution because we are now committed.

Typically Planning Poker sessions produce estimates, but the real by-product is the consolidated solution vision that the entire team, including the client, has after the session. (In addition to the prioritized User Stories) That is the real value. Not producing estimates leaves the project in much poorer state.

The Guarantee

Why do we believe so strongly in this? Because we focus on the end state or the ultimate Solution. By focusing just on the Software Development process and activities you can Sub-optimize and although the Software Development process can be better (however you define better), the overall value of the project can be diminished or possibly no longer apply. Not producing estimates is one example of potentially many where having a focus just on the Software Development process may adversely affect the raison d’etre of the overall initiative.

Just like outsourcing the act of Software Coding can result in less than optimal solution elsewhere in Software Development, not estimating a Software Development projects can create a less than optimal solution for the entire initiative or business.

Protegra believes so strongly that Agile projects can be successfully estimated that we have an offering to guarantee scope and budget with our clients when we are able to execute Custom Software Development Projects in our Lean and Agile Methodology. It is something we have been doing now for over 10 years.

User Story Points and User Story Hours

This Blog post may be somewhat controversial, but I really think it provides a viewpoint that I don’t normally see represented. I urge you to read the entire post before jumping to conclusions. Here goes:

The Politics

I’ve read many a good post on estimating Agile projects, but I must admit the discussion about estimating via User Story Points versus User Story Hours seems to suffer from partisan politics. If someone believes in User Story Points, they paint the only alternative as a bleak Orwellian future of accounting for time in 5 minutes increments and shock therapy for the failure of missing estimates. They usually also assume that if you don’t buy in fully to User Story Points, you also don’t believe in Agile in general, Planning Poker, and are an avid fan of Waterfall. Nothing could be further from the truth.

What I would like to have is a bi-partisan discussion of the pros and cons of different estimating approaches.


Before I start I would like to state that I believe that User Stories, Planning Poker and Story Point Estimating should be done on each and every project. What I am discussing and proposing here is not about not doing Planning Poker and Story Point Estimating, but rather discussing whether the estimating should stop there or continue with other additional methods.

The Continuum

There is a continuum of approaches for estimating. This is illustrated in the diagram below:

When discussing the pros and cons of Story Point Estimating, we are usually limiting our discussions to just the two extremes. I would like to propose a hybrid approach as well.

Agile The Agile approach is the one that is most commonly proposed in the Agile literature. This approach proposes estimating by User Story Points and these estimates are typically generated in a Planning Poker Session(s). The Planning is then done by planning the Iterations based on the number of User Stories and their associated points.Success is then usually judged by being able to achieve a stable User Story Point Velocity from which to execute the remainder of the project in iterations. This Velocity is used in an iterative and ongoing basis to refine the plan for subsequent iterations based on past results.
Traditional The Traditional approach is defined by creating very detailed task level estimates in hours. These estimates may be done by the team, but usually are done without the team or with a subset of the team. These estimates are usually created without the input of developers. The Planning is then done by creating a Work Breakdown Structure. The Work Breakdown Structure is then applied over a timeline or schedule to create the fully detailed Project Plan.Success is usually judged by the accuracy of the task estimates which will then translate into meeting the estimated schedule generated from the Work Breakdown Structure.
Hybrid The Hybrid approach proposes estimating by User Story Points and these estimates are typically generated in a Planning Poker Session(s). The Planning is then done by planning the Iterations based on the number of User Stories and their associated hours. The User Story Hours are created by converting the User Story Points into User Story Hours.Success is then usually judged by being able to achieve a stable User Story Point and Hour Velocity from which to execute the remainder of the project in iterations. The User Story Point Velocity is used in an iterative and ongoing basis to refine the plan for subsequent iterations based on past results. User Story Hours are provided to the owners of User Stories so they know what the original estimates of the User Stories were.

What are the pro and cons of each approach?

Well we all know the pitfalls of the Traditional approach, so let’s not even discuss that approach. 🙂 But why is the Hybrid approach compelling when compared to the Agile Approach? In fact, the Agile and Hybrid approach are very similar except for the fact that the planning is done in User Story Hours and the velocity is measured in User Story Points. In addition, User Story Hours are then provided to the owner of each User Story to provide a frame of reference as to the initial estimate. Let’s look at the pro and cons of Agile estimating concepts and how User Story Hours can help mitigate the cons.

Concept Pros Cons How do User Story Hours help?
User Story Points Minimizes the human element of having duration or hour perceptions influence estimates. May force the ‘slotting’ stories into non-ideal slots. (i.e. It is a 30, but all I have are 20 and 40 slots) Provides a second review once you have converted to User Story Hours to ensure the estimates are consistent and make sense.
Relative estimating Establish standard grouping and increase accuracy by relative estimating. Also leverages human ability to excel at relative estimating. Creates single point of failure. Base line estimate which all other estimates are relative to can create a ripple effect of estimate inaccuracy. This may take multiple iterations to correct. Remove single point of failure with reality check. Second review will ensure estimated hours make sense.
Planning poker Increases team buy in, shares estimating expertise and promotes team growth, helps to refine solution understanding, and increase estimating accuracy. None. Not Applicable. This concept is used in both the Agile and Hybrid approaches.
Velocity and Burn down Validate estimates and plan at a macro level. Not at an individual, user story or task level None. Not Applicable. This concept is used in both the Agile and Hybrid approaches.

Perhaps the most important benefits of User Story Hours are that they allow for the derivation of a project budget and schedule. One of my biggest challenges with the User Story Points approach is the concept that it will take two or three iterations to determine your velocity and then you can inform your client when you can complete the project and how much it will cost. Very few projects I have been a part of can get a blank cheque for two or three iterations and then confirm if the project is feasible and has business value. User Story Hours still allows you to have that check at the end of each iteration AND also create an estimate at the start to ensure the budget and schedule satisfy the project’s business case. Although the estimate still is not ideal, it is better than not having an estimate at all.

And please stop saying that we shouldn’t estimate at all. Just stop, you are hurting innocent people. 🙂

I believe it is disingenuous to propose something as a principle that you know applies to a very small minority of projects. We need more ideas to bridge this reality gap of executing project in an Agile way and requiring project estimates up front to validate a business case.

The Data

I’ve read many posting on the perils of converting User Story Points to User Stories Hours and how a common conversion factor may not be feasible due to the difference confidence factors for each User Story size. I believe this is a red herring. The postings discuss how the conversion factor will be more of less accurate for different stories of different sizes. I couldn’t agree more. And it doesn’t matter.

All we are concerned with is if the conversion factor holds on average for the entire project. I’m not expecting it or requiring it to apply to individual estimates. I’m not holding individuals accountable for User Story Hours for each User Story, as I know these items will follow a Normal Distribution. (In fact the studies I have seen have prototypical Standard Distributions. An excellent post by Mike Treadway illustrating this can be found here: http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html)

Let’s look at the data Mike Treadway compiled:

User Story Points Average Estimated Hours Average Actual Hours
1 8 6
2 5.5 4.5
3 5.67 5.33
5 5.4 5.8
8 4.75 4.375
Overall Average 5.864 5.201

In this example,converting to and using Estimated Story Point Hours results in an 11.3% difference between estimates and actuals. This is very much in line with the 10-15% project contingency commonly quoted. So it appears that this method is not introducing additional inaccuracy. Please note I am not saying you don’t continue to manage in an agile way monitoring velocity and adapting as you execute. But this would allow for a checkpoint before you start your project that your schedule and budget are feasible. Without this I fear we may give Agile a bad reputation by starting projects that should not have even been started because they did not satisfy the business case.

I also realize that the User Story Hour Velocity will change from iteration to iteration. This factor does not take away from the value of converting to User Story Hours. Trying to use this argument is another partisan point where the argument implies we are going to use the conversion factor to manage in a traditional manner. We are not. We are using the User Story Hours to only plan and manage in an Agile manner. The important factor for both User Story Points and User Story Hours is that we manage by Iterations and at a higher level of abstraction so the individual deviations in estimates are expected and do not matter.

So given the fact that we need to convert to User Story Hours to validate the budget and schedule before we start, why wouldn’t we use them in addition to User Story Points as we manage iterations? I can’t think of any reason but I’d like to hear opposing viewpoints.

Two Final Points

1)      The conversion to User Story Hours is done by the team and changes are only made by the team. There is no Project Management influence to modify the hours. This is absolutely critical.

2)      I’ve heard the comment that providing estimates in hours will affect the developers doing the User Stories and they may alter their behaviour and deliverables. I believe User Story Hours is merely another piece of information that developers should have when undertaking a story. I think having the User Story Hours will let the developer provide feedback immediately if the estimate is incorrect and allow for immediate adaptation. Otherwise we may only find out that our velocity is an issue a week into an iteration. Why wouldn’t we want to know if there are concerns immediately? Developers I have polled have stated they would like to know the initial hour estimate to be able to possibly raise a red flag early. They stated User Story Points do not allow this to be done as easily.

I’d like to hear why people are averse to using User Story Hours and communicating User Story Hours to developers. I’m sure there are some factors I have not discussed.

I think the benefits realized by developers knowing the initial estimates outweigh the dangers of the developers working to those estimates. A true Agile environment and team can allow User Story Hours to be used for good rather than evil.

Please let me know if you find this interesting and whether you would like to see a subsequent post on how you can convert from User Story Points to User Story Hours.