Posts Tagged "agile project management"

Choosing the Right Measure of Progress

Posted on Aug 9, 2014 | 0 comments

Choosing the Right Measure of Progress

What is Progress? Defining progress will help you to better understand the difference between being busy and productive. Unfortunately, I often see very intelligent and productive people falling into the trap of doing busywork instead of making progress. In order to effectively combat this problem, it helps to define progress much in the same way we define a vision: envision the end state. Attempt to describe in detail the properties and aspects of the ideal end state for your current task or project. For example, if I was trying to build an office chair, I may describe the end state as follows: “I can sit comfortably in the chair for several hours,” “The chair is elevated from the floor,” or “I can rotate the seat of the chair easily.” Each of these properties can be easily measured, whether objectively or not, and represent true progress toward completing my goal. Tasks do not represent progress. Continuing with my example from earlier, there may be many things that I need to do in order to build a great office chair. Perhaps I need to buy materials such as wood, steel, and fabric. Maybe I need to sketch designs, cut out upholstery, and assemble arm rests. All of these things represent actions that I can and probably should do in order to reach my end goal of having a lovely new office chair, but none of these things represent true progress. Tasks act as hypotheses to be tested, not the results of an experiment. For each task you decide to act on, you make an implicit statement: “If I complete this task, then I will be closer to achieving my goal.” Experience probably tells you that even the most successful and accomplished people regularly learn otherwise. At the end of each completed task, and often before, we learn about new tasks that must be completed. For example, before you can buy wood you need to find a store that sells the wood. Perhaps the store is closed and you now need to find another store or different wood, let’s say you chose to change to a different kind of wood. Now, the store that sells the new wood is open, but when you get there, they have run out and recommend another store. You don’t have enough gas to get to the other store, so you start off toward the gas station. We now have a situation where in order to make progress on my chair, I must go to the gas station. If I measure productivity by the tasks completed I may find that I am immensely productive, checking off task after task after task. However, without any measurable and tangible progress being made on the chair itself, I am failing to achieve my goal. How you measure progress directly impacts whether you feel most productive doing busywork or accomplishing your goals.  Measure Real Progress The real challenge with choosing a measure of progress is recognizing incremental steps toward a goal that represent true progress and not the busywork of tasks that may or may not contribute to the goal. This can sometimes be more art than science, but focusing on realized benefits as a measure of progress will almost always deliver results. Since user stories are the primary measure of progress on most Agile projects, it is important that they represent realizable benefits as opposed to tasks. Using our existing example to tie everything together here, the following benefits would be great measures of progress on our office chair. The chair has a designated seat. The seat is elevated from the floor. The elevated seat can hold...

Read More

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