Posts Tagged "estimation"

Predicting Scope, Schedule, and Cost

Posted on Jul 16, 2014 | 0 comments

Predicting Scope, Schedule, and Cost

Every project has three key variables… The three key variables that project managers must manage are typically scope, schedule, and cost. Businesses tend to create project plans that assign constant values for these variables at the project outset, therefore creating the illusion that projects have fixed scope, schedule, and cost. So before we continue, allow me to dispel a myth so we can start down the road to improvement. Fixed scope, schedule, and cost is an insidious falsehood that undermines the entire project management institution and community. Whether or not you openly admit it… This is a true statement; and I must assume you understand and have seen the truth in your experiences on real projects. We propagate this lie despite the deleterious consequences. However, I believe that there are important sociocultural reasons why we do this, so don’t beat yourself up if you still live the lie. What is more important is the acknowledgement that in the real world scope, schedule, and cost are not fixed, and we must become excellent at predicting these things for business planning and management purposes, no matter what process we use. Agile projects have a unique set of challenges in predicting scope, schedule, and cost that differ from traditional projects. This is because Agile projects are managed differently… Different in key ways that impact scope, schedule, and cost. Below are some excerpts of the relevant principles of the Agile manifesto. Scope: “Welcome changing requirements, even late in development…” Schedule: “Deliver working software frequently, from a couple of weeks to a couple of months…” With constantly changing requirements… We need a way to measure and predict the final scope of a project that not only allows, but welcomes change. Furthermore, we must deliver a working product on a shorter timescale than the 12+ months that is sometimes typical in the IT industry. Lastly, if our customers and executive sponsors are accustomed to infrequent product revisions, then it is quite likely that despite any incremental releases, we will still need to predict and communicate the future delivery dates of major product features that are in development for several months (or even years) at a time. Okay, enough build up, how do we predict successfully? I will share with you some tried and tested techniques that I have been applying very successfully at my clients for some time now. However, I must warn you in advance, these are advanced techniques that will take some time and patience to understand and apply, so be prepared to run experiments and learn from your mistakes. Create a predictive model. I have found that the best way to model Agile software product development is by first assigning a relative point scale to user stories, which we refer to as “Story Points.” Numerically speaking, using a fibonacci scale seems to yield the best predictions, so we will use that scale. It’s important that this step is done correctly, and that the story points are relative to other user stories, not a point of reference, like “1 point is equal to 1 day of development.” Instead, a 1-point story must be roughly equivalent in effort to any other 1-point story, and a third less effort than a 3-point story. On Agile projects it is wasteful to break down long-term projects into fully defined user story backlogs because we expect detailed requirements to change, so we must also assign relative sizes to larger work items (I will use the term “feature”) that we haven’t broken into user stories yet. We can use the same fibonacci scale, but to avoid confusion, I recommend...

Read More

Planning Poker: Optimized

Posted on May 7, 2013 | 0 comments

Do you enjoy the benefits of fast, accurate estimation on your team by using “Planning Poker”? Interested in squeezing a little bit more waste out of the process?  I have a relatively simple technique that I have applied successfully over the past several years to do just that. It may seem like planning poker is already a very highly optimized estimation technique, but just like anything else, there is always room for improvement. Planning Poker Overview First, for those who may be unfamiliar with the technique, let’s review the technique and some of the reasons why it works so well.  On most traditional software teams, estimating of work is done either by the developer who will do the work, or a technical lead of some type, or in some cases, a project manager.  Regardless of the individual that performs the estimation, it is typically performed by one or very few individuals with expertise in the field.  And in what unit do we typically estimate?  Hours, days, man-months, or some calendric equivalent is the canonical unit of measure for work effort for most traditional software teams.  So, how do we improve on this technique with planning poker? Planning poker improves on the standard technique in three key areas: accuracy of estimates, effort required to estimate, and identification of risk.  To improve the accuracy of estimates, planning poker asks a team to estimate collaboratively as a team as well as hiding our “guesses” to avoid being influenced by others until we are ready to share as a group.  Next, the technique reduces the total effort required to estimate because instead of using a unit of time that is influenced by many environmental factors it uses a unit of relative effort by comparing one piece of work to another.  Lastly, teams identify risks and assumptions by discussing why their private “guesses” differed from each other.  For more detailed information, see Mike Cohn’s wonderful description of Planning Poker. Here’s the basic technique: Product Owner/story author explains the user story to be estimated Team discusses the story and asks clarifying questions Individuals choose estimates from a deck of possible values (1, 2, 3, 5, 8, 13) and keep them private On a count of 3, the team shares their private estimates with each other Discuss differences and revote until we converge on one number Planning Poker: Optimized In order to further optimize this technique, we need to understand how mature teams using planning poker can exhibit waste in their process.  There are a few key areas where a good coach, ScrumMaster, or other facilitator will try to time-box the team to improve throughput: the user story overview, team discussions, and non-converging revoting.  These are the main areas that can exhibit waste (even on highly efficient Agile teams) because the criteria for when they are complete is not typically well understood.  Hopefully I can help change that! Let’s optimize the user story overview first.  In order to test and validate the written communications of the team, ask that the story author read the story in full, which usually includes a narrative and perhaps some notes or preliminary acceptance criteria for completion.  For situations where a user story is little more than a title, offer the story author no more than one or two minutes (timed!) to explain the story, and then ask the team to hold all questions and comments. In lieu of possibly wasteful discussions, require that the team produce a “rough draft” estimate based on the short overview they have already been presented.  This minor adjustment to the order of operations for planning poker...

Read More