Your boss wants a commitment.  You want to offer a prediction.  Agile, you say, only allows you to estimate and predict – not to commit.  ”Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.”  There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.

This is an article about agile product management and release planning.

Change and Uncertainty

In the dark ages before your team became agile, you would make estimates and commitments.  You never exactly met your commitments, and no one really noticed.  That was how the game was played.  You made a commitment, everyone knew it would be wrong, but they expected it anyway.  Maybe your boss handicapped your commitment, removing scope, lowering expectations, padding the schedule.  Heck, that’s been the recipe for success since they planned the pyramids.

It makes sense.

1. Your early estimates are wrong. When you add them up, the total will be wrong.  If you do PERT estimation, the law of large numbers will help you in aggregate.  But you’ll still be wrong.
2. The outside demands on, and availability of, your people will change. Unplanned sick time, attrition, levels of commitment over time, lots of “people stuff” is really unknown.
3. The needs of your customers will change. Markets evolve over time.  You get smarter, your competitors get better, your customer’s expectations change.

Agile processes are designed to help you deliver what your customer actually needs, not what was originally asked for. Contrast the two worlds.

In the old world, you would commit to delivering a couple pyramids. After spending double your budget, with double the project duration, you would have delivered one pyramid. When you deliver it, you find out that sphinxes are all the rage. Oops.

Your team changed to agile, so that you could deliver the sphinx. But your Pharaoh still wants a commitment to deliver a couple pyramids (the smart ones will be expecting to get just one).  You can stay true to agile, and still mollify your boss’ need to have a commitment, if you take advantage of the first-principles of why agile estimation works.

Estimation

A commitment is a factual prediction of the future.  ”This will take two weeks.”  Nobody is prescient.

A factual prediction has to be nuanced.  ”I expect* this will take no more than two weeks.”

*in reality, this is shorthand for a mathematical prediction, such as “I expect, with 95% confidence, that this will take no more than two weeks.”

Few non-scientist, non-engineers, non-mathematicians understand that 95% confidence has a precise meaning.  People usually interpret it to mean “a 5% chance that it will take more than two weeks.”  What it really means is that if this exact same task were performed twenty thousand times (in a hypothetical world, of course), then nineteen thousand of those times, it would be completed in under two weeks – do you feel lucky?

To make a statement like this, you actually have to create a PERT estimate – identifying the best-case, worst-case, and most-likely case for how long a task will take.

Unfortunately, we’re rarely asked to make a commitment about a single task – but rather a large collection of tasks – well-defined, ill-defined, and undefined.

You can combine PERT estimates for the individual tasks, resulting in an overall estimate of the collection of tasks.

The beauty of this approach is that the central limit theorem, and the law of large numbers, work to help you estimate a collection of tasks – you can actually provide better estimates of a group of tasks than a single task.  This obviously helps with the well-defined tasks that you know about at the start of the project.  This even helps with the ill-defined tasks.  Rationalists will argue that the key, then, is to do more up-front research to discover the undefined tasks – and then we’re set.  As Frederick Brooks (Mythical Man-Month) points out in The Design of Design, this debate has been going on since Descartes and Locke.  It is not a new idea.

Big Up-Front Design and Requirements (BUFD & BUFR) hasn’t worked particularly well, so far.

Don’t throw out the baby with the bath-water, however.  The math of estimation is still important and useful.  Even if empiricism is not the silver bullet.

Prediction

Estimation is a form of prediction.  Even agile teams do it.  In Scrum, you estimate a collection of user stories – in story points that represent complexity, and you predict how many points the team can complete in this sprint.  Note the time factor.  If you’re working a two-week sprint, there is very little risk of changes in staffing during a two-week period.  There’s also very little risk that your market will change significantly in two weeks – and if it does, what are the odds that you will notice and materially change your requirements in two weeks?

Visually, let’s take that PERT estimate and turn it sideways – so we can introduce the dimension of time.  Imagine you estimated all of the tasks (well-defined, ill-defined, and a guess about the undefined), as if they were all to happen in the first sprint.  Ignore inter-task dependencies, and pretend you had unlimited resources and the ability to perform all tasks in parallel.

The graph above shows the aggregate estimate – the circle is your best prediction, with error bars representing your confidence interval in the estimate.  If you were using PERT estimates, these could represent that 5% and 95% confidence lines.  Subjectively pick something based on your team’s experience in the domain and your confidence in your guesses (about the undefined tasks).

We need a segue into the “best of waterfall” approach to estimating projects, to steal and invert a good idea.

The Cone of Uncertainty

The folks at Construx have published a nice explanation of the cone of uncertainty – an adaptation of an idea from Steven McConnell’s Software Estimation: Demystifying The Black Art (2006).  That article uses his imagery with permission – so please go look at it there.  The idea is that as the project becomes better defined (e.g. during the project), the amount of uncertainty is reduced.

The findings show that initial estimates are off by 400% (either low by a factor of 4 or high by a factor of 4)!  Even after “nailing down” requirements, estimates are still off by 30% to 50%!

As bad as that sounds, it is actually worse.  This is a prediction for the original project (delivering pyramids).  Not only are your estimates wrong – but they are bad estimates for delivering the wrong product.

But – the core idea is sound – the further into the future you have to execute, the greater the mistakes in your estimate.

Taking that concept, and applying it to our diagram, we get the following:

The further into the future you are trying to predict, the less accuracy you have in your prediction.  This reduction in accuracy is reflected as a widening of the confidence bands for your estimate.

• A couple sprints’ worth of work is not much different than one sprint – so your estimation range is not much changed.
• An entire release of sprints (say 6 to 10 sprints) has much more opportunity for the unknown to rear its head.

Now, your prediction is (probably) unusably vague and imprecise.  ”This set of tasks will take X plus or minus a factor of two.”

That’s the reality.

Note: This has always been the reality.  People have historically reduced this “risk to timing” by hiding the “risk of change” aspects – and waterfall processes encourage you to deliver the wrong thing, as close to on-time as possible.

That’s not what we want to do, however.

We still want to deliver the (not-yet-defined) right product, as efficiently as possible.  That’s the goal of agile.  (For folks who haven’t been here at Tyner Blain for long – “right” includes both value and quality).

Refinement

Because we’re agile, and we’re willing to “get smarter” about our product over time, we have an opportunity to improve.  Because of the nature of compounding estimates and the cone of uncertainty, our uncertainty gets smaller over time.

Let’s remove our artificial simplification that we could do everything “right now” and look at what we think we know right now, about the end of the release.

Our ability to predict the amount of effort (for today’s definition of the product) at the end of the release is not very good.

Our ability to predict (today’s definition of the product) one sprint into the future is much better.

After completing the first sprint, we are a little bit smarter – the ill-defined tasks are better defined.  Maybe some of the undefined tasks are now ill-defined.  The same cone of uncertainty is now a little bit smaller – we are a little bit smarter, and the time horizon of the release date is a little bit closer.

The trend continues – each sprint gets us closer to the release date, and with each sprint (assuming we get feedback from our customers, and continue to study our markets) we get a little bit smarter.  We also get better at predicting the team’s velocity (how much “product” they can deliver during each sprint).

Commitment

Your boss still wants a commitment, however.  And that’s where we get to change the way we look at this (again).

The above diagrams all display how we converge on an estimate for a stable body of work.  However, we know that the body of work is constantly changing.

Backlog! [you say]

Yes!  The backlog.  The backlog is an ordered, prioritized list of user stories and bugs.  I was talking with Luke Hohmann of Innovation Games last month, and one of the most popular online Innovation Games is now the one they created based on prioritizing by bang for the buck.  Play it today online (for free!).  How cool is that?

The backlog represents the work the team is going to do – in the order in which the team is going to do it.  Over time, as we get smarter, we will add and remove items from the backlog – because we discover new capabilities that are important, and because we learn that some things aren’t worth doing.  We will even re-order the backlog as we recognize shifting priorities in the markets (or in our changing strategy).

As this happens, it turns out that the items at the top of the list are least likely to get displaced, and therefore most likely to still be part of the product by the time we get to the release.

Instead of thinking about uncertainty in terms of how long it takes, think about uncertainty in terms of how much we complete in a fixed amount of time. In agile, generally, we apply a timebox approach to determining what gets built.

Now, uncertainty, instead of manifesting as “when do we finish?” becomes “what will we finish?”

Your boss is rational.  She appreciates the constraints, she just wants to know what you can commit.  Every boss I’ve worked with has been willing (sometimes only after much discussion) to treat this uncertainty in terms of what instead of when.  They acknowledge that they need to translate (usually for their boss) into a “fixed” commitment.

The solution: commit to a subset of what you predict you can complete.

At the start of the release, you may have 500 points worth of stories.  Based on your team’s expected velocity, and the number of sprints in the release, you predict that you can complete 320 points worth of stories (5 people on the team, a team velocity of 40 points per sprint, and 8 sprints in the release).  Starting at the top of the backlog and working down, draw a cut-line at the last story you can complete (when you reach 320 points).  This is your prediction.

Now the commitment part.  You’ll have to figure out what you’re comfortable with.  Maybe for 8 sprints (say, 16 weeks into the future), you may only be comfortable committing to half that amount – 160 points.  Go back to the top of the backlog, and count down until you reach 160 points.  Everything above the line is what you commit to delivering.

Maybe you are comfortable committing to 240 points, maybe only 80.  This is like playing spades.  The more you can commit to, without missing, the better off you are.  Your tolerance for risk is different than mine.

You can also negotiate with your boss.  Commit to 160 points now, and provide an update after every other sprint.  More likely than not, you will be increasing the scope of your commitment with every update.

Mid-project updates of “we can do more” are always better than “we can do less.”  And both are better than end-of-project surprises.  This also allows you to have updates that look like this:

We didn’t know this at the start of the release, but X is really important to our customers – and we will be able to deliver X in addition to what we already committed.  Without slipping the release date.

Conclusion

Making commitments with an agile process is not impossible.  It just needs to be approached differently (if you want to stay true to agile).  The end result: better predictions, more realistic commitments, and the likelihood that each update will be good news instead of bad.

[Update: Changed initial image.  Thanks Dennis for the great photo!]

Engagement – that’s what this whole product management blogging thing is about.  Check out what Tyner Blain readers found to be the most engaging articles in 2009.

Deep Dives

If you’re new to Tyner Blain, you may be surprised by the length of the articles here.  I joke that they are long because I don’t have time to edit.  Stewart Rogers jokes that they are long because I’m incapable of writing a short article.  If you’ve been here a while, you know what you’re in for.  If you’ve been here a long while, then you’re glad (like me) that I don’t write one per day any more.

Product Management is simultaneously a broad and deep discipline, requiring us to have a breadth of perspective combined with a depth of insight.  We then have to apply that in a market context, effectively navigating the political waters of our organizations.  Most of the articles here either try to skim the breadth of a range of related topics, or plumb the depths of a single topic.  Doing that in under a thousand words is pretty hard.  Most of the articles here also link to other articles, to try and provide even more depth and context, and encourage additional critical thinking.

One measure of the quality of the articles here is how often they stimulate readers to read further, or dive deeper into the topics.  While web analytics won’t allow us to measure how thought-provoking an article is, we can look to see how many people dive into the linked articles, versus how many people move on to something else.  We can measure the bounce rate of an article to see how often people leave a page without following any of the “tell me more” links.

Looking at ~170,000 page views at Tyner Blain in 2009, narrowed down to only those articles with at least 100 page views, here is the top-ten list of most engaging (or “least abandoned” if you’re a “cup is half empty” person) articles:

1. Use Case Series: Introduction: A collection of articles on the “traditional” forms of use cases – informal, formal, UML.
2. Agile Development of Use Cases: A dive into the dynamics and cadence of an agile process for developing use cases.
3. How Do You Manage Market Data?: A collection of articles exploring different market-immersion techniques in depth.
4. Scheduling Requirements Changes – Part 2: A focus on practical techniques for managing change with an agile development process.
5. Yesterday’s BPMN Post Was A Big Fat Lie: A mea culpa and clarification of interest to folks following the BPMN Series.
6. Everything I Needed To Know I Forgot in Kindergarten: Why asking why? is important.
7. Plan Your Next Sprint by ROI – Part 1: Prioritizing by Bang for the Buck, not just Bang.
8. Ten Common Mistakes of Going Agile: A collection of articles about common pitfalls encountered when adopting agile practices.
9. Perpetually Almost Finished Projects: Organizing a project with discrete deliverables and rolling-wave planning to avoid the “90% done, 90% remaining” problem.
10. How To Use Timeboxes for Scheduling Software Delivery: One of my personal favorites.  A rational approach to making trade-offs when your “perfect” plan has to change.

OK Stewart, that’s only 519 words.

Creating a PERT estimate for a single task is both easy and straightforward. Creating an estimate for a set of tasks is still easy, but requires a little bit of math. Combining PERT estimates for tasks is easy, but not as obvious. Roll up your sleeves and dive in.

PERT Estimate Refresher

When estimating how long it will take you to complete a task, you shouldn’t estimate with a single value like “four hours.” “Four hours” does not provide enough information. Estimates reflect that there is uncertainty, and that single value does not give you any insights into how uncertain your estimate is. Your estimate could be “four hours plus or minus one hour” or it could be “at least four hours, maybe as much as sixteen hours.”

A PERT estimate, as we showed in our earlier PERT estimation article represents a distribution of likely effort for a particular task. To create a PERT estimate, you create three values -

1. The “best case” (shortest) amount of time it will take to complete the task.
2. The most likely amount of time it will take to complete the task.
3. The “worst case” (longest) amount of time it will take to complete the task.

A PERT estimate is presented in the form “Best Case / Most Likely Case / Worst Case.” If your estimate is “four plus or minus two hours” you would write 2/4/6 as a PERT estimate. Sharing “2/4/6″ as an estimate still doesn’t tell anyone else what you mean. A PERT estimate embodies some probability around completion time. You are precisely saying (for a 2/4/6 PERT estimate):

1. There is a less than 1% chance that this task will take less than 2 hours.
2. There is a 50% chance that this task will take less than 4 hours.
3. There is a greater than 99% chance that this task will take less than 6 hours.

This explicit statement of probabilities represents a distribution of likely outcomes. Statisticians would phrase it in a confusing (but mathematically important) way. They would say “if we sampled a large population of people (like you) doing this task, no more than 1% of them would complete the task in under 2 hours, no more than 1% of them would spend more than 6 hours on this task, and half of the people would complete the task in under 4 hours.” For the purpose of estimation, you can ignore the statistic-speak and just look at the “odds” of how long it will take you to complete the task once.

[larger image]

If you were to create a histogram of thousands of executions of the task, it would look like the diagram above.  This is the traditional bell curve shape we are used to associating with a normal distribution, but it actually represents a PERT estimate.  A PERT estimate is a distribution of possible outcomes, based on a beta distribution.  Another way to look at a PERT estimate is in terms of cumulative probability of a task being completed.  The same data in the graph above, when presented as a cumulative distribution function (CDF) looks like the following:

[larger image]

Here’s the rub – you don’t really know if the beta distribution is the right one.  Primarily because you can’t precisely know the actual probabilities.  So, you have to pick a distribution function to represent those probabilities.  There is debate about the right distribution function to use for estimation – check out this great article for hard core stats guys.  Here’s a cautionary warning from their conclusions:

Although bias stemming from misspecified activity time probability models is rarely mentioned in introductory discussions, we have seen several instances of this bias in simple examples. First, and perhaps most important is the uncertainty as regards the underlying activity time probability models. The literature offers no less than five procedures for translating the subjective estimates (a,m,b) into specific β-distributions. As shown, the methods lead to distinct β-distributions, and the PERT approximation need not satisfactorily estimate any of them.

Essentially, they are saying “you can’t really know the right shape for a distribution curve of possible outcomes – so don’t get carried away.”  And they then go on to suggest using a simpler model than the beta distribution for estimation.  Their suggestion is to use a triangular distribution (looks like a triangle, instead of a bell curve), because the math is easy.  With spreadsheets, we can still do “easy” math with a better distribution

The beta distribution for a symmetrical PERT estimate looks very much like a normal distribution.  You can see this by comparing the cumulative distribution function of the PERT and normal models for this 2/4/6 example.

[larger image]

Based on this similarity in distribution, and the inherent uncertainty in what the shape of the distribution really looks like, there are some benefits to treating the PERT estimate (2/4/6) as a normal distribution where the high and low values represent +/- 3 sigma bounding.  This approximation provides us some benefits when aggregating individual task estimates into combined project estimates.

Continued on the next page…

There’s really only one way to travel down a waterfall – in a barrel.  A lot of people died this way, but some survived.  Software projects have been predominantly waterfall projects since the start of software projects.  And stakeholders rode down those projects, basically in a barrel.  The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end.  Stakeholders in waterfall projects don’t know if they will succeed until the end.

An agile project is dependent upon tight interaction (and feedback) with stakeholders.

If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?

Expectations, Documentation, and Communication

The success of any project is dependent on setting and managing stakeholder expectations.  In Managing Stakeholder Goals, we talked about assuring that those goals are addressed by our requirements.  And in a later article, we proposed a way to balance the goals of different stakeholder groups when those goals are in opposition.  Those are good tools for making sure we are initially aligned with what we are hearing from stakeholders.

We need to also apply active listening techniques to assure that what we thought we heard is what the stakeholders thought they said.  One way to do that is to write use cases (or user stories) so that we can communicate the intent of the product back to the stakeholders.  This still primarily helps with kicking off a project, in the desired direction, with the correct goals.

There are many ways to document this initial intent of the project and stakeholder goals.  It is analogous to a stakeholder selecting a sturdy barrel and picking a good spot on the river bank to push off.  We’re well positioned to eventually succeed, assuming nothing changes.  After a harrowing fall, we find out how well we did.

A well-run waterfall project will provide status updates to the stakeholders along the way.  Imagine your stakeholder wearing one of those in-helmet headsets that NFL quarter backs use.  We publish effective status reports to let the stakeholder know what’s going on.  Like the falling barrel, however, a waterfall project has inertia.  The project, barring significant outside influence, will keep going in the direction it started.  Projects have change control boards to manage that change, but emotionally, I find that a formal change-approval process tends to inhibit change, rather than encourage it.  That barrel will keep falling.

Some project teams will try and do very heavyweight documentation to maximize the likelihood that the project will end up where it should.  The problem is, this heavyweight documentation only improves the chances that the project will end up where we used to think it should go.  It does not help us change the trajectory of the project as new insights are gained.  Just as responding to those changes provides a competitive advantage, ignoring those changes exposes a competitive weakness.  Someone will come along and exploit your weakness if you don’t respond to change.

From these dynamics, we can conclude that “big up-front requirements”, while better than “no requirements,” are actually a waste of energy and time, relative to an ongoing adaptation to change.  That adaptation to change, however, should also be documented.  It needs to be documented for two reasons – to manage expectations of stakeholders, and to keep the implementation team focused on creating the most valuable capabilities in your product.  As you get smarter about what is valuable, you need to apply that knowledge and change the path of the project.

This is where communication becomes critical with stakeholders too.  Especially the old-school barrel-riders.  They are used to being in the barrel, maybe with an occasional “looking good – you’re still falling straight down” message along the way.  They are not used to hearing “we’ve decided that gliding over the rocks is more valuable than falling – please extend your wings now” messages.  The shocked “what wings?!” response is what they immediately think.

Agile Expectations

An agile project will avoid the big up-front requirements, and gather just enough requirements for right now.  What your stakeholder might hear is “agile is magic – we don’t need detailed requirements.”  The real message is “agile is better – we don’t need details about the requirements yet.  But we will need them later.”

A given team needs the same amount of specificity in requirements to achieve the same result, regardless of project approach.  One team I worked with would not set the tab-order in a form to go from top to bottom if you didn’t specify that.  It simply didn’t occur to them.  Another team was very effective with “gather the following data in a form…” – and they would layout the form, manage tab order, add reasonable field validation, assure proper markup and support for screen readers (for visually impaired users), and implement a candidate error-message/feedback design for users.  The first team would never succeed without details, the second team would view those details as wasted effort by me to write them, and by them to read them.

I think most of the initial creators, proponents, and early adopters of agile processes are members of the second camp.  They designed agile to not require detailed documents, but to allow it when needed – because they acknowledged that some people need the details.  They were reacting to heavyweight processes that were designed to work for “any team” at the cost of slowing down the best teams.  Kent Beck told me once that when people tell him about the importance of testing, his response is “so, lack of testing burned you before?”  When people stressed the importance of gathering requirements, his response was “you’ve been burned by a disconnect with stakeholders.”

Enough is the operative word here.  You have to document enough.  You have to communicate enough.  You have to set expectations with your stakeholders that things will change.  And as those things change, you have to stay joined at the hip with your stakeholders to validate those changes.

While your team is responding to changes (based on feedback from stakeholders and the market and competition and implementation discoveries) with new plans, you have to feed that information back to the stakeholders.  It is a two-way communication.  And it needs to be a continual communication.

I joined a six month project once in the last month of the project.  Here’s a sanitized sequence of events describing what happened.

1. Initial vision for the project was defined and requirements defined and tied to goals and value.
2. The estimates came back and said “no way it will happen before the business-imposed deadline.”
3. The team said “let’s be agile” and chose a component of the vision to do first.  That component could be completed by the deadline, and stakeholder expectations were set – (a) do this visible thing first, “meet” the deadline, and then (b) regroup, re-prioritize, and then do the next thing next.
4. The team started developing the solution, and worked for 5 months.  After 5 months, someone concluded “we won’t finish by the deadline.”  A couple weeks later, the estimate was that the team still had between 1/3 and 1/2 of the work remaining to complete the first component of the vision.
5. In presumably unrelated events, all but 2 of the internal stakeholders left the company.  Literally.
6. When the CIO and president of the company engaged the project team, they weren’t thinking “we have an over-run on the first component of our vision” – they were thinking “not only is it not done, but what you’re trying to do is not the right thing.”
7. Project was stopped one week after the original deadline for the first component (which was not completed).

It may be that this was unavoidable, but one thing was clear – the “build the first thing first” expectation was not communicated effectively.  It didn’t help that the team did not track velocity, so it wasn’t until the end of the project when the “you’re going to hit the rocks” message was first heard by the stakeholder in the barrel.  Way too late to affect change.  For this and other reasons, I contend that the project was not agile.  It was a Chevrolet with a Ferrari sticker on it.

We can ignore the labeling of the process and focus on the lack of ongoing expectation management as the ultimate doom of the project.

Evolving Expectations

Patrick Masi had a couple great comments on our Simple Agile Model article.  Patrick pointed out a problem with simple documentation artifacts like this.  The early “here’s all we need right now” artifacts were insufficient to capture the full extent of what the stakeholders needed.  I’m not sure exactly where things broke down, but Patrick implied that the ongoing clarification with stakeholders was not happening.

This is a completely different manifestation, I suspect, of the exact same problem described above.  Thinking about Patrick’s comments is what got me heading down the whole “barrel rider” path in the first place.

I don’t believe I’ve worked with any stakeholders who would say “yes, ignore what we learned this year – it is more important to build last year’s product.”  I’ve definitely worked with stakeholders who did not have time to commit to the support of an agile project.  The ironic thing about agile projects is that they may do more requirements work through the course of the project than non-agile projects.  An agile project will respond to change.  That means some work is re-done.  It also means that some valueless work is avoided.  You can’t categorically say which influence is larger.

One possible source of the pain Patrick’s team felt is mis-set expectations of what is being delivered when.  Imagine developing a checkout-process for an eCommerce website.  The complete checkout process is too large for a single sprint, so you break it down into valuable atomic deliverables for each sprint:

1. Registered customers can buy any products, using previously saved billing / shipping info.
2. Individual product and “per order” discounting works and customers can use gift cards to pay for all or part of the order.
3. Anonymous customers can place orders (without accounts) and registered customers can modify billing and shipping information.
4. Orders can be placed as gifts (with gift receipts and wrapping services), and online call-center reps can interact with customers real-time to help with the process.

This is a nuanced message – basic checkout in sprint 1, with increasing capabilities in each sprint, until “complete checkout” is done in sprint 4.  That is a reasonable plan, but requires a more detailed conversation with stakeholders so that they know what is coming and when.  You don’t want someone freaking out after the 3rd sprint when they can’t place gift orders.

Another possibility is that the elicitation process before the third sprint (re-visiting checkout again with the same stakeholder) did not tease out that anonymous users must provide an email address (for order confirmation email, and to secretly create a “shadow account” for that customer).  All of those details need to be gathered, and it can be harder to spread out the conversation over multiple sprints than it is to have it all up front.  This is just incomplete discovery, but with delayed (and recurring) impacts.

In User Stories Applied, Mike Cohn stresses that the brevity of user stories is intentionally designed to facilitate (and I would add “dependent upon”) conversation.  I find it to be both a strength and a weakness of user stories.  It is strong because you can cover a lot of ground quickly (breadth) and capture a number of stories, much like the list above.  It is weak because the requirements documentation does not stand on its own – it requires conversation to fill in the details.  I’ve had some success using the “Verify that…” user acceptance tests as the method of documenting those details (depth), in conjunction with the brief, easily consumable stories.

You can write the stories quickly to decompose and schedule across sprints (revisiting the schedule as things change), and then write the verify statements as UAT for each sprint as it occurs.

Another benefit of the UAT is that it is explicit and cuts through the walls of the barrel for a stakeholder who “doesn’t get agile” as Patrick puts it.  “Here’s our lightweight multi-sprint plan – now lets define the specific acceptance criteria you need” is a pretty effective conversation.

Conclusion

You have to stay closely connected to your stakeholders – not just for messaging, managing, and changing the big-picture direction of the project, but also to drill down into the details at the last practical moment.

An effective status report is one that

• Instantly conveys the state of the project.
• Creates a minimum of overhead for the project team.
• Gets you help when you need it, and latitude when you don’t.
• Is fun / energizing to the author and the readers.

An effective status report is not a myth, it is actually easy to achieve.

Goals of a Status Report

You do not create a status report because someone told you to create them.  You create a status report only when it benefits the project.  There are three effective uses of a status report:

1. Get help (escalating) when you need help.
2. Keep stakeholders in the loop so there are no surprises.
3. Get visibility for the accomplishments of the people on your team.

Problems of a Status Report

There are also potential downsides of creating status reports.  This doesn’t mean you should avoid creating a status report.  It means you should avoid status report mistakes.

1. A bad status report takes a lot of energy (and time) to write, making it expensive.
2. A bad status report is difficult to read, causing it to fail to communicate.
3. A bad status report covers up problems or cries “Wolf!” when things are under control.

Elements of an Effective Status Report

The following is one example of an effective status report format.  Other formats can work.  This one does.  We’ve been using it for months on multiple projects, with great success.  On one of our projects, the first status report in this format was forwarded around by the project sponsor for people to “check this out!”  Ever hear of that happening to one of your status reports before?  In a good way?

There are five components in this status report format.

1. The scannable forecast.
2. Last week’s accomplishments.
3. This week’s planned accomplishments.
4. Issues and resolutions.
5. The legend.

The Legend

Normally, we run through a list in order.  In this case, we will show the last section first.  The legend explains how to read the first section, the scannable forecast.

You can define any number of different statuses for a project.  “Red, Yellow, Green” is the most common.  A couple years ago, we proposed this metaphor for status reporting:

A great way to do this is with a stoplight metaphor (at least in the US, where green = go, yellow = caution, red = stop). We can provide a little color in our reports to make the status details and rollup easy to scan. When someone is the audience of a status report, its because the reader needs to know what is going on, but isn’t involved – and likely is reading status reports from other teams. We need to present a document that gives a quick visual that guides the reader to pay attention to the most critical elements.

• Red. Immediate action (by the reader) is required to fix this.
• Yellow. We’re at risk of failing to meet expectations. There’s a plan in place, but we thought you should know. Want to know more?
• Green. Meeting or exceeding the plan. No need to spend cycles on this one.

[Update 28 Apr 2007: We have a much improved metaphor for tracking project status - weather forecasting.]

It works, but it isn’t great.  You’ve all seen it, because it is adequate.  However, using red, yellow, and green to provide a scannable status can be confusing – even if your readers aren’t colorblind.  Does red mean the project is delayed?  Yellow usually means a project is at risk.  But is it “at risk, help is needed” or “at risk, FYI, help is not needed.”  That’s part of why we recommended the weather forecasting metaphor.  Thanks again to Johanna Rothman for originally sharing the idea.

The Scannable Forecast

When you look at the above, even without knowing any details  you know:

1. The project is in worse shape this week than it was last week.
2. The project will get worse before it gets better.
3. The team has it under control, today, but might need help next week.

Last Week’s Accomplishments

The bulleted list is extremely effective for scannable details.  The secret – use three to five bullets.  More bullets means you’re sharing too much, and fewer than three is not enough.  You’re reporting to a project sponsor who has placed trust in you to manage the details.  Your sponsor, when things are sunny may not even read the details, just relying on you to say “everything is great.”  The only time that you need to share more details is when things are stormy.  And those details (1) will come up in the issues section, and (2) will come up in conversation.

When someone on your team does something noteworthy, dedicate one of your bullets to that accomplishment.  If you have a dozen of these, then refine your definition of noteworthy.  You should already be providing feedback to your team about their work.  Noteworthy accomplishments should be broadcast up the chain.  Its a reward for their hard work.  Don’t under-report, and don’t over-report.  The people who consistently do great things will begin to get a positive reputation where it counts.  As a bonus, you will get acknowledgment for being a good manager.

This Week’s Planned Accomplishments

This is what you intend to do in the next week.  When your project sponsor does want to get a little more insight, perhaps to make sure that she believes that you will resolve things, she will read these details.  Again – a three to five item bulleted list is appropriate.

Issues And Resolutions

You report issues when you are (or anticipate being) cloudy or stormy.  You don’t waste your sponsor’s time on trivial issues that you can resolve on your own.  These are issues that either definitely require escalation, or may require escalation.  Again, you’re working a three to five item list.  On your project, you will potentially manage ten times as many risks, and you could track them in a spreadsheet, etc.  Those are the issues you are working.  These are the issues you need help to resolve.  And only the issues you need help to resolve.

Note that this isn’t just an issues section – it is issues and resolutions.  When you inform a stakeholder that you need help with a problem, the first thing you need to do is propose a solution.  Imagine the following exchange:

“I need help” – “What do you need?” – “I need you to ….”

Much better than

“I need help” – “What do you need?” – “I don’t know.  I need help determining what I need.” – “I know what you need, you need help updating your resume.”

For every issue, propose a solution.

The issue section is also not meant to be a standalone document.  Here’s another bad exchange:

“I need help” – a couple days go by – “I solved your problem for you.  And I’m replacing you with someone I can rely on.”

Your project sponsor shouldn’t have to ask what you need her to do.  She should, however, want to know why you think the proposed solution is best – and you should talk to her about it, not present a rationale within your status report.

Practical Experience

I’ve created many status reports using this format.  They take anywhere from 15 minutes to 45 minutes, almost always under 30 minutes.  When they did take any significant time, almost all of that time was spent in thinking about the content to report in the “Planned Accomplishments” section.  And that is not time that I spent writing a status report – it is time I spent planning, on those occasions where I procrastinated in my planning, and the writing of the status report triggered a brief planning exercise.

Brevity in a report goes a long way.  As does regular face-to-face (or at least phone-to-phone) conversation.  A status report alone better not be the only way you communicate.  It should be a light-weight artifact that (1) starts the important conversations, (2) preempts the time-wasting conversations, and (3) provides an archive that you can review later, to see the full arc of the project, gain insights, and run your next project even more effectively.

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

Product Success Is Not Easy

Saeed Khan wrote a critique recently, in On Product Management, of an article by Phil Meyers on the Tuned In blog. Phil’s article is an analysis of the pending re-organization at Starbucks, and the one quote that Saeed keyed in on was:

At the end of the day, its simple. Create a product or service that your buyers want to buy and the rest takes care of itself.

Saeed’s point is that it is not that easy. A lot of hard work goes into creating a successful product. And Saeed’s right.

Maybe Phil’s point is that the executive should not worry about the details, and trust in his team to do all the hard work. But he doesn’t really come out and say that, so we can’t really back him up on that front. Let’s give him the benefit of the doubt anyway. There’s another point that Phil makes that is potentially disturbing:

Looking at metrics like average same day sales and products per square foot lead you down some strange paths. Schultz even admitted as much in a letter from the board about a year ago in which he worried about the company ‘losing its core’.

Yes, abandoning your goals to pursue your metrics is bad. But don’t abandon your metrics to pursue your goals – unless all you want to do is get lucky.

You might argue that a company like Animoto got lucky when their product spread virally within Facebook and their user base jumped from 25,000 to 700,000 users. But if you listen to the interview that Amber MacArthur did with co-founder Brad Jefferson, you will realize that it was only when they tweaked their product offering – a response to empirical analysis of product adoption metrics – did their success explode. I would argue that they made their luck by being intentional.

Empirical Processes

When you can perfectly model your business analytically, you can measure the inputs and know (with certainty) the outputs. As a college engineering student, I learned this. Real world processes can never be perfectly modeled analytically. As a professional engineer, I learned this too. Real world processes are empirical. The secret to great engineering is to apply analytics to those empirical processes to create disruptive innovation, and combine it with empirical controls that help you statistically predict the likely outputs. The answer is simply that neither analytics nor empiricism alone can help you achieve greatness.

Business processes are also empirical in nature. Even when you can devise an analytical model for the behavior of an isolated system, you have to acknowledge that no real world system is isolated. You have to expect unexpected inputs into the system. As Saeed points out, you have to apply analyses to make smart decisions when developing your process (or business model, or product). And what Phil appears to discount is that you also need to apply empirical measurements to your process (or business or product) to control the expected results.

Creating Successful Products Intentionally

This article proposes that there are two paths to product success. The first path is simple. Cross your fingers, then get lucky. The second path is harder. Be intentional.

1. Identify your market (and therefore your customers and competition).
2. Identify their problems, and select the ones you will solve.
3. Create a product roadmap (aka a “plan”) to solve those problems.
4. Design and implement solutions to the most valuable problems.
5. Get feedback on your solutions.
6. Incorporate your feedback into your plan (step 3) and repeat.
7. Revisit your market (step 1) and the problems you choose to solve (step 2) and repeat.

Note: Step 7 should occasionally replace step 6, so that you stay focused on your market, and not just an out-of-date snapshot of what used to be important to your customers.

1. Identify Your Market

There are a lot of ways to pick a market to focus on. You can chase demographics – there sure will be a lot of retired people in the US thanks to the baby-boomers. You can go with what you know – years of paying attention to an industry presents ample opportunities to understand the market. You can create an entirely new – blue ocean – market by solving problems people don’t even realize they have until you offer a solution. Choosing a market is the subject of many books, not just an item in a list.

Once you choose a market, you need to segment the market into groups of people who share the same problems and who value solutions to those problems similarly. You can apply market research to improve your market segmentation.

2. Select The Problems You Will Solve

You use elicitation skills to identify the problems that your customers face. And when you have to address multiple market segments, you can prioritize the problems across those market segments.

3. Create a Product Roadmap

Once you’ve prioritized the problems you are going to solve, create a product roadmap. Your product roadmap should show the problems you are solving, and the order in which you will solve them. When you define sequencing, you also must define your approach to scheduling product releases.

4. Design and Implement Solutions

There are two keys to successful execution of the plan you built with your product roadmap. First – use rolling-wave planning to define near-term details and long term vagaries. Second – make sure you have continuous integration as a key component to managing quality throughout the process, instead of checking quality at the end (or even worse – ignoring quality).

5. Get Feedback on Your Solutions

This is half of why agile (when done right) works [Can you believe the discussion over the last year on this article is up to 27 comments?!]. Feedback is not just something you get when sharing a prototype with stakeholders. Feedback is also something you must get as part an incremental release methodology.

You can even measure the ROI of your designs, and incorporate feedback at the design level.

6. Incorporate Feedback Into Your Plan

There’s no point in gathering feedback if your organization and your process are organized to resist changes to the plan. Contrary to what the Standish Group’s CHAOS study has always implied [and we've made this implicit mistake too], release schedules are not the primary measure of project success. In a fantastic article at Dr. Dobb’s Journal, Scott Ambler points out that in his survey results, almost two thirds of professionals find that doing the right thing is more important than meeting a project schedule.

Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.

Do the right thing. If the right thing involves changing the schedule, that doesn’t make it wrong. What makes this work is the fact that you are getting feedback early and often. It is a risk mitigation strategy, designed to reduce the possibility that you will create an unsuccessful product. It is not a strategy designed to keep your project on schedule no matter how mis-aligned you are to your market.

7. Revisit What You Are Doing And Why

If step 6 is small-scale course correction, this is large-scale course correction. You may discover that solving a big problem for your customers exposes a new “biggest” problem that wasn’t there before. By revisiting step 2, you can choose to tackle or ignore those newly discovered problems.

You may also discover that by leveraging your investments to date, you dramatically improve the ROI of solving problems in another valuable market segment. This is because even if solutions to those problems have the same value, solutions to those problems now have much lower costs (for you). By revisiting step 1, you give yourself the opportunity to best manage your strategy, your resources, and your plans.

Conclusion

Product Success may have an element of luck, but you should never plan to hit the lottery. Be intentional in what you will do, and a good plan, executed well and adapting to change, will get you there.

We’re dedicating our “blogging time” this week to doing some infrastructure upgrades – we have to address some security issues on the site. Until we get through these changes, we’ll be recycling some of our existing content. For our recent readers, it will be “new to you” and for our long time readers, we appreciate your patience. Today we look at one of our most popular articles – on using Timeboxes to manage your project plan.

How To Use Timeboxes for Scheduling Software Delivery

A timebox is a fixed unit of development capacity. An easy way to visualize a timebox is as a two-dimensional graph. Along the vertical axis is the cost of the development team (per unit time). Along the horizontal axis is time. The longer an iteration is, the wider a timebox is.

The important thing to notice is that with Cost and Time fixed, the capacity of the timebox is fixed. There is only so much that can be accomplished with a given team and a given amount of time.

Bill Miller, who writes You Want it When?, a blog focused on improving the way you manage software development and I had a debate over email about outsourcing. We looked at pro’s and con’s, and our discussion centered around the best outsourcing model, and what the ramifications of outsourcing really are. Read on to see the back-and-forth.

The Context

Bill and I started this debate based on the following:

• We really enjoyed some back and forth discussions that grew around other topics we had written about previously and wanted to do it again. We both really respected the other person’s well-reasoned positions, and both felt that we learned a lot from the other person.
• We thought it would be even better if we were able to open the conversation up to others – so we decided to have a debate that we would then post to our blogs so that other people could join in, or at least see reasoned arguments on both sides of the issue.
• There are a lot of thorny issues where reasonable people can disagree. We looked forward to discussing one of them, and look forward to discussing more of them.

Bill had a great suggestion – we are each posting a copy of the back-and-forth (we couldn’t figure out a usable way to make you go back and forth between our blogs). If you want to make a point or ask a question of Bill, post it to the copy of the debate on his blog. If you have a question for me – post it here.

The Outsourcing Debate

Scott

What do you think the best model for offshore outsourcing is? To narrow the field (initially, I’m sure it will expand as we go), let’s use this article to frame our discussion:

Outsourcing Models for Software Development (at ThinkingStreet.com)
I think the best model, when trying to write innovative software is to start with low-level outsourcing, until you work out the kinks in operations and develop mutual trust. Then I think you should move to high-level outsourcing and leverage the increasing skills of the team you’ve partnered with. I don’t think you should go to the next step of complete technical outsourcing. As much as some people want to believe that it is effective, and it may be, in the short run, it is a recipe for long term failure. If you lose the capability to innovate technically – both in products and process (QA, etc), you die a slow death. Further, I believe the collaboration of “to solve this problem, I think we should do this – what do you think?” is easier than an open ended charter across cultural, language, and temporal boundaries to “solve this problem.”

Bill

I’ve read your article and your email that started this off. You’re email actually raises a number of issues that we can discuss. I’ll start on this one: “I don’t think you should go to the next step of complete technical outsourcing. As much as some people want to believe that it is effective, and it may be, in the short run, it is a recipe for long term failure.“ We have to get some better definitions of what complete technical outsourcing means. What if the technical center is owned by the company is that complete technical outsourcing? For example, at one multi-national company I worked at, we opened up wholly owned offices in India and moved entire products to be developed in India. Would you consider that complete technical outsourcing? The motivations for opening the technical centers in India were entirely based on saving operating expenses. When I was at another multi-national company, they had development offices on every continent on the planet except for Antarctica. Is that complete technical outsourcing? When you have another company do the work in a remote office, is that the only form of outsourcing? The challenges are similar whether you own the offices or you contract for the people. If you hire a company in the same city to do all the work, is that complete technical outsourcing. I’m trying to understand what about outsourcing is unique that makes it a slow death if it’s complete. Is it distance, the fact that another company is doing it, both or something else?

Scott

You die a slow death when you outsource everything, because you are outsourcing your innovative capabilities along with the contract to create short-term innovations. Neither of the multi-national company examples you gave have that problem. In both examples, you’re keeping your intellectual property “in house.” I would say, generally, that the location that does the work is the one best equipped to invent the future. As long as your company owns it – and is ok with the innovation coming from that location, then great. But if you don’t have control / ownership of the group doing the work, you’re doomed to a slow death.

I agree with you that all geographically distributed teams face the same execution challenges more or less. That element is just one of efficiency. If the extra impedance and (presumably temporary) inefficiencies of transitioning work to a different (again, presumably) lower cost provider are smaller than the savings of distributing the work, it makes sense.

But not when you give away the responsibility outside of your company.

Bill

The employees at both multi-national companies that I worked at felt there was no difference between a consulting outfit taking the work and an offshore development center being created to take on the work. Most felt the fact that the work was moving away from the originators the project was doomed to failure. They thought it was doomed to fail because the team and the knowledge base was destroyed in the process – true for either model. Do you really lose the IP when you give the work to a consulting company? I don’t believe so because the requirements, designs, and code are all owned by the company doing the outsourcing. Isn’t the IP the artifacts? Programming, managerial, and QA skills are not so unique that they cannot be reassembled elsewhere. The fact that they are reassembled from the US to let’s say India in the form of an outsourcing model is proof of that these skills are readily available. There are inefficiencies in reassembling teams that slow progress down, but once the team is up to speed, they should be just as effective as any capable team of doing the work.

Scott

Maybe “slow death” is too harsh. How about a door rusting shut? You can open it again, by reinvesting in getting the IP back into the company, but you are introducing an effort and challenge that must be overcome to do it. When you “outsource” within your company, you are only moving the expertise and “off cycle inventiveness” that comes from having a working familiarity with the space. When you outsource outside your company, you no longer have anyone who can do that work (without a ramp-up or investment period).

Imagine that you are a publisher of horror novels. You have in-house authors that write for you. You sack them, and get freelance authors to write books for you. Initially, they are writing on spec – creating books based on ideas your authors already had. Eventually, they are writing books based on their own ideas. Being immersed in the horror genre for a while, they’ve gotten pretty good at it. And they ship you all of the books and outlines.

Then one day, the authors decide to cut out the middle-man (you) and self-publish.

Just because you have a stack of books and outlines that they created for you does not mean you are in a position to write and publish horror novels any more. You have to start over.

Bill

Some people use off shoring and outsourcing interchangeably, and I was looking to understand if you were too. As I understand you, you see them as two separate models: off shoring works and outsourcing is a death sentence. I’d like to explore that more, but I need to understand your position on IP better before I can.

You seem to be using a nonstandard definition of IP. IP is a product of people’s minds: art, technology, design processes, solutions to a problem, trademarks, patents, etc. These are all protected by international law. Companies own IP; they don’t own people. The IP isn’t lost when you outsource or offshore. I tried finding a definition that supported your use, and I was unable to find it. Here’s one reference to IP definition on a Cornell University web site. http://www.library.cornell.edu/newhelp/glossary.html#I I don’t accept that IP is lost when companies outsource or offshore unless they give it away in the contract. I’d like to understand better what it is that you feel a company is losing when they outsource to respond more effectively.

Scott

Great points, Bill. I believe that the phrase “invest in your people” is more than a platitude – that years of immersion in, exposure to, and thinking about a domain creates an unrealized asset in the minds of the people. You’re absolutely right that “yesterday’s ideas” are your property in an outsourcing arrangement. I see those as two different classes of asset. But they are both intellectual assets, and in some respects, they are both property. Hence my liberal use of intellectual property as a short-hand description of the stuff in people’s heads.

When you’re investing (implicitly) in the heads of the outsourcing employees, you are doing it at the expense of investing in your own people.

And this effect will only be felt in the long run – “yesterday’s ideas” have the same value regardless of who invented them. And as you point out, in an outsourcing arrangement, you own those inventions. Since few management decisions are made with the long run in mind, it is easy to see the allure of outsourcing as a short term cost reduction with no tangible or immediate down-side. My contention is that there is a long term down-side.

Bill

I can’t say I like the changes taking place in the IT industry with regard to outsourcing and off shoring, but that’s only because of my own personal reasons. The corporate world is changing. I don’t believe it makes sense to fight inevitable change. Globalization is here to stay, and so are it’s consequences to how we work. It’s similar to the changes that occurred in the 18th century at the dawn of the industrial revolution with similar effects on how people live and work and how business is conducted. But I don’t believe all the outsourcing is motivated out of cheap labor because of globalization. It’s because the software industry has matured and global commerce is changing business practices.

As the corporate world evolves, many activities that were once done in house are now outsourced: whether it’s through a consulting arrangement or the purchase of services from a 3rd party provider. This makes obvious sense when the services or products are not strategic for the company. For example, ADP and Paychecks do payroll processing for many companies. It should be cheaper for a company to purchase this service from ADP and Paychecks than to hire staff and support this in house. Few companies have IT departments for payroll services any longer. For many companies IT is just a tool like a typewriter or copy machine. It never made sense for a company to build its own typewriters and copy machines, and they didn’t, and so for many companies, it doesn’t make sense for them to write their own software and manage their own computers either. They will never be any good at it because it’s not their business.

How did we get here with companies getting into the software development business when that was never the purpose of their business in the first place? Why should Hospitals or Insurance companies have IT departments? These are support services. We got here because the software industry was new, and there weren’t businesses that companies could go to, to purchase the software they needed, so they created it in house because it made financial sense. The return was greater than the investment. Now that the software business has matured, there are companies providing products and services that 20 or 30 years ago were unavailable. The industry has now matured where companies can purchase what they need rather than build it in house. So now they have started the process of unwinding the departments that they would have never created in the first place if software wasn’t such a nascent industry.

This is mostly a win-win situation. It is always a better career choice for an IT professional to work at ADP developing payroll processing systems than to work at Aetna, for example, developing payroll processing systems. At ADP payroll processing is a profit center and a core competency for Aetna payroll processing is a cost center and a necessary chore. At Aetna if the payroll processing system is working well, there is less motivation to improve it. At ADP there are competitive reasons to improve the payroll processing system. This usually means that the IT person working at ADP will be keeping up with the changes in the field faster than the IT person working at Aetna. (note, the company names are only used as an example to illustrate a hypothetical point.)

As for the concern that investing in the heads of outsourcing companies is a competitive disadvantage, I don’t see it for a few reasons. If Aetna outsources to ADP its payroll processing system and ADP develops talent that gets really good at this, I don’t believe Aetna lost anything strategic in the process. Now if a company hires an outsourcing company to develop a unique application that gives it an advantage in the marketplace, I still don’t believe a company loses anything here either. Let’s take Wipro; it would be bad business for them to offer contracting services and then start competing with the companies they offer contracting services to. I don’t believe any company has anything to fear from Wipro entering into their market space. Wipro is a multi-billion dollar software contract house; they are going to look to make their next billion growing that business – not entering the businesses of their customers. Second, all of these contracts have agreements for who owns the software created etc… It would be a breach of contract if they were to break that agreement, and there are legal remedies for it. Let’s assume the employee quits Wipro and enters the market themselves; that’s no different than any employee today quitting and doing the same thing, and it’s done all the time today.

I still struggle to see the loss of inventiveness that you speak of. I actually see an enhancement of inventiveness for many of the kinds of companies that I’ve described in this response. These companies are freeing up capital to invest in the reasons they went into business in the first place. With that extra capital, they have the opportunity to invent even more because less is being spent on non strategic purposes. Outsourcing for many industries has been with us for decades. The IT profession has been experiencing it marginally as well for decades, but we’ve hit an inflection point where the change has been dramatic. This is permanent. The companies that learn how to manage this successfully will win in the marketplace.

I believe, instead of the software professionals fighting this inevitable trend, we should be looking to accept it and recommend how to adopt these changes successfully. There’s no turning the clock back, and the dire predictions are specious. Oh some will fail at this, but many that do are probably already struggling with IT in the first place. If we do accept it, the possibilities for IT professionals in this new model are boundless unless, of course, the only measure of good is to see that you are doing things today the way you did those things 20 years ago. The world leaves those behind who don’t move on. We may be the early 20th century equivalent of a blacksmith. It would have been a mistake for the blacksmith to not accept the change that was upon him. Likewise, the 21st century software engineer needs to accept the changes that are upon us. Only then can the software community begin to build the future that is possible. Fortunately, the need for software engineers will not vanish like the blacksmith, but what will change is the niche we fill in the value chain. Only when we embrace change can we conquer change. When we fight change, change conquers us.

The end?

We create cost estimates at many times in a project. From budgetary estimates at the start of a project all the way to PERT estimates of tasks in a work breakdown structure. Creating a budgetary estimate seems impossible – you have to make many assumptions, your estimates are based on the unknown – they can’t be good. There are ways to make budgetary estimates easier to generate and refine – but they can create a sense of false precision.

Small Tasks Can Be Estimated Accurately

We wrote before about reasons that a project plan will fail. One of those reasons is bad estimates. One of the best ways to assure that you have reasonable estimates is to manage the size of those estimates. When you keep your estimates to tasks in the 1 to 8 hour range, you are forced to put additional thought into design, implementation gotchas, and you end up making better estimates.

Early Estimates for Large Jobs

At the other end of the spectrum, we sometimes have to build budgetary estimates for large jobs. Jobs that are too big to estimate in terms of small tasks – at least in the time that we have to create the estimates. Use case points can be used as a framework to provide a reasonable estimate of large jobs. To use a use case points analysis, you have to have an understanding of scope and goals that allows you to identify a set of use cases, with enough detail to know how complex they are.

Sometimes we have to make estimates before we have the level of detail needed to apply use case points (or other structured techniques) to build a budgetary estimate.

Our only hope for very large, ill-defined estimation is to create a very rough estimate – in man-days or man-months.

Just Kidding yourself

You can make an argument that any estimate of a project so poorly defined that you don’t know the use cases well enough to estimate them is a waste of time – that you’re just kidding yourself. If you are trying to build an accurate estimate – we agree. But you sometimes have to make decisions without accurate estimates. A business often has to make relative decisions about which projects to pursue, before there is detailed information which can take time to gather.

OK, so you’re in an impossible position – what do you do?

1. Breath.
2. Plan for the future.
3. Build a budgetary estimate (also known as a rough order of magnitude estimate).

Breath

Recognize that you’re the “expert” and your executives are looking to you to give them some insight about how big the job is.

Planning for the Future

When you do an early, budgetary estimate, you should expect that you will be iteratively refining that estimate – maybe multiple times per day. And you’re estimating something large, with a lot of moving parts, and a lot of assumptions. If it wasn’t a large, complex, messed-up, ambiguous affair, you would have been able to make better estimates. So plan on making a lot of changes to the estimates.

Building A Budgetary Estimate

Don’t look at a big project and say “It’s 1000 man-months” and call it a day. Decomposition helps you make better estimates on small tasks – the same is true on large projects. So, decompose as much as you can. If you’re estimating an enterprise deployment of multiple applications, break down the estimates to a per-application level. Assuming you can’t go any further, estimate the effort at this level. Then set up a spreadsheet to roll up the estimates for the applications into an overall estimate.

There are some other things you can look at at this point

• Sequencing – are there any obvious dependencies that force serial development activities? What can be done in parallel.
• Staffing – do you have an unlimited supply of team members, or do you need to stagger development due to resource constraints?
• Regional teams – can you split the development or testing to outsourced or regional teams?

These inputs help you with staggering the allocation of effort over time. They also allow you to apply a burden rate for the labor (based on financial models for staffing costs).

Iteration

Your spreadsheet should roll all of the costs (over time) up to final numbers. You end up with a whole bunch (maybe hundreds) of “small numbers” that, with assumptions, become one big number.

Then you show this to your executive – who sees hundreds of numbers, and one big number. Improperly positioned, your executive will walk away believing that the big number is precise, because the estimation looks complex. This introduces a sense of false precision. You know that the “small” numbers are educated guesses. So adding it all up gives you just one big educated guess. If you miscommunicate at this stage, you could be setting yourself up for disaster. Your exec might shoot down the project because of your unacceptably high estimate. Or even worse, commit you to a dangerous and impractically low estimate.

The way you climb out of this morass is with iterations. So plan your spreadsheet to make it easier to change. Get better estimates, validate assumptions. Start detailed planning. With each iteration, remove an unknown. Create a better estimate for a subset of your massive project. The more time you have, the better your estimate becomes. Just keep in mind that it is still budgetary, until you use a rigorous estimation technique like the ones we mentioned above.

Directional

Now you’ve uncomfortably delivered a budgetary estimate, hopefully set expectations so that it will be received the right way. You’ve improved it as much as you can with the time you have available by iterating. What now?

Breath again.

Your estimate is likely to be directionally correct, however wrong the actual numbers may be. Your estimate is going to be compared with other estimates that are likely to be just as inaccurate. But your numbers do provide some insight into the relative sizes of the different projects. And they will allow executives to make the best decisions they can on very limited information.

Conclusion

Do what you have to do. Understand how suspect the numbers are. And make them better, as much as you can.

You’ve written a project plan. Your team is ready to start. Here’s the bad news – you’re going to fail. But why? How can you avoid failure?

The Undergrad Mistakes

Failing to plan is planning to fail. We’ve all heard this one before. Its become a cliche. Steve McConnell opens his article, The Nine Deadly Sins of Project Planning with this old saw. Well, we certainly can’t argue with that. And Steve offers some other suggestions that also fall into the project management 101 class – don’t use the same plan for every project, plan for risks, don’t plan in too much detail too soon, to name a few. Let’s assume we know that stuff already.

Christopher Hawkins provides us with project management 211 topics in his article, Why Your Schedule is No Good – And How to Fix It. He goes into detail on six more common mistakes:

1. People take vacation – is that in the plan?
2. People get sick – is that in the plan?
3. Don’t forget holidays. And for global teams, don’t forget holidays in other countries.
4. What about personal days?
5. Have you planned for disaster? Christopher adds 5 days of contingency to a 3 month project.
6. No-one is productive for 8 hours per day – is that in the plan? We plan on 5 or 6 hours of “on task” time per day.

His article is a really good one. These are the things you know to do if you’ve managed projects before. You didn’t do them because someone told you to do them – you planned for these because they happened (and they always happen), and you got burned. So you remembered.

The Graduate Mistake: Everything Is Late

Doug DeCarlo has an article at Gantthead, Why Traditional Project Planning Often Fails. He applies some interesting insights, that help put things in perspective.

First, he cites a variation on Parkinson’s Law, that the tasks will grow to fill the allotted time. They may not all be late, but many will – and few will be early. In addition to “feeling right” intuitively, this has some mathematical impacts on the schedule that I don’t believe any estimation software accounts for.

When you run two tasks in parallel, and one or both are late, you’re done when the last of the two finishes. By running tasks in parallel, you can infer that they are independent. Unfortunately, this isn’t universally true when planning. When tasks are run in series and the first task is late, the second one starts late.

A Quick Refresher on PERT
When we look at traditional PERT analysis, we have a mathematical way of dealing with this. Imaging two tasks estimated to take 4/6/8 hours (best case / likely case / worst case) each. With PERT estimates, you are saying that 90% of the time, the task will take between 4 and 8 hours. Each task has a 5% chance of taking more than 8 hours, and a 50% chance of taking more than 6 hours.

When you run those two tasks in parallel, that means you only have a 25% chance that your project will finish in 6 hours – the odds are that at least one of the tasks will run long. And you have an almost 10% chance that your project will take more than 8 hours. If you’re running 5 tasks at once, you have a 23% chance that the project will take more than 8 hours.

Many people will think that if they have 5 tasks, running at the same time, each with a 95% chance of being done in under 8 hours, that they have a 95% chance of being done in 8 hours. They don’t. The problem is that you aren’t done until all the tasks are done. And you only have a 77% chance that they will all be done in under 8 hours.

Where PERT gets interesting is when the tasks run in series. The two 4/6/8 tasks will complete in 9/12/15 with the same expectations – 95% of the time, the two tasks will have finished in under 15 hours. The odds get better because sometimes, when one task runs long, the other one runs short. This is the interpretation of combining PERT estimates.

Back to DeCarlo

The problem, according to DeCarlo, is that the tasks will never come up short. Does this mean that PERT estimates are junk? No – it just means that our estimates might be. Imagine the task were ten times as large, with a PERT estimate of 40/60/80. Suspend for a moment your urge to reject an estimate that large. 40/60/80 is symmetrical. That means you believe 40 to be just as likely as 80. If DeCarlo is right, then 55/60/80 would be much more believable. This would represent that the task often runs long, and almost never runs short.

Thankfully, we can still combine PERT estimates in this way. If our two tasks were in series, and were estimated as 5.5/6/8, the final project estimate would be 10/12/14. The final distribution has tightened up, as we would expect – because the original estimates are tighter.

We think DeCarlo is at least on to something. When reviewing project post-mortems, we do find that under-estimated tasks exceed over-estimated tasks, by about 2 to 1, at least for tasks in the 2 to 8 hour size range.

Make sure and review the estimates – and pay particularly close attention to the “low side” of the estimate – is it really believable?

The Post-Hole-Digger Mistake

That’s how my grandfather described people with doctorate degrees. He felt that practical knowledge was worth more than theory. This works well for the last mistake, because for some people, this one is well, duh – practical, and for others it is enlightened study – aha! smart.

Your project is a moving target. Your project plan is a static document. Instead of proving it to you, I’ll quote Bill Miller from his blog, You Want it When?,

A project with no requirements changes is either mismanaged or a dead project walking. If the project you are delivering is something that has a future and the project stakeholders are excited and interested about, requirements change is an inevitable consequence.

Bill Miller, Embrace Change

Read the rest of Bill’s article – it’s really good. He and I have been discussing the warts and merits of agile project management, and reminiscing about the good old days of waterfall development and rotary phones for a while. Seriously good insights and healthy skepticism of the hype you see everywhere (even here, sometimes).

• When requirements change, deliverables change.
• When deliverables change, the work tasks and estimates change.
• When tasks and estimates change, the project changes – and so should the plan.

You don’t have to tell anyone if this was obvious to you, or if it seems enlightened – don’t ask, don’t tell. And if you haven’t been on a project where the project manager refused or at least resisted changes to the plan, you haven’t been on very many projects.

Conclusion

There are many things that can go wrong with project planning, ranging from the obvious to the insightful. From the high level (plan for change) to the low (be wary of symmetrical PERT estimates). The more of these things you plan for (pun intended), the better your plan will be. Most importantly, realize that your project is a moving target, so your plan better move with it.

What can you learn about your agile project from this Gannt chart? The one above looks out two years. It shows task dependencies and concurrencies. If you’re iteratively developing software, do you really expect to know what you’ll be doing two years from now, to know if you truly have a dependency? You may understand the dependencies with a two-month time horizon. But how much effort are you investing in creating a detailed, two-month Gannt chart? And how much value are you getting from it?

Hat Tip

Hat tip to Johanna Rothman, who doesn’t like Gannt charts, and who linked to an awesome article by Tate Stuntz, The Demise of the Gannt Chart in Agile Software Projects.

The Demise of the Gannt Chart

Tate starts his article with a nice statement about Gannt charts. Namely, Gannt charts work for manufacturing processes. In effect, he points out that they work because Gannt charts are good for optimizing systems with dependencies – and manufacturing processes have relatively immutable dependencies. Tate’s basic premise is that agile software development is so mutable, both strategically and tactically, that creating a Gannt chart of the process is both hard and of questionable value.

One thing I really like about his argument is the way he starts with an analogy to show the value of Gannt charts. He points out that Gannt charts are effective for managing projects with sequential dependencies (the argument applies to finish-to-finish, staggered start-to-start, and other types of sequential dependencies, not just finish-to-start dependencies).

He points out the obvious efficiencies of re-use and parallelism that can come from over-arching project sequencing. He uses the canonical house-construction model: build the foundation, then the other parts next. He also alludes to the argument that software development does not require this model to be in place. To reinforce that argument, consider pre-manufactured homes, where the walls may be constructed in advance of pouring the foundation – the dependency is severed.

Tate argues that agile teams sever these dependencies all the time. And he points to some elements of agile development that enable this – or arguably, are required if you want to sever.

• Generalist team members. Generalists can re-sequence tasks within an iteration as they see fit. To quote Tate -
  

  “Well, if your Agile project goes like the ones I’ve seen, the team members will display the irritating behavior of constantly moving around to different tasks as seems most effective to them within the iteration – regardless of what you’ve written down.”

  And I agree, based on my experiences too. His argument is that the predictability that comes from using specialists comes at the cost of efficiency, due to bottlenecks introduced into the system. I don’t know if that’s true, from my own experiences, but it may be. I suspect that an optimized dependent/sequential system can be as efficient as a severed system. The point to remember is that agile is designed to deal with change, so change causes fewer cascading ramifications. It makes sense to argue that the dependent system is less efficient, given the presumption of change.

• Pair programming. An interesting point about pair-programming is that it spreads knowledge throughout the team – making them modular. This modularity reduces or eliminates resource-constrained sequential dependencies. In other words, whatever tasks make the most sense to be done now, can be done by anyone who is available, rather than only the person who understands it. This is a variation of the generalist staffing model – but it is the practice that increases the generalizing nature of the participants.
• Refactoring and Regression. Tate argues, as have we, that automated regression testing is critical to being able to change and refactor. This is a key tenet of continuous integration, something that every project should use, regardless of process.

A very interesting argument. Tate also cites Scott Ambler’s survey of agile adoption rates as showing that Gannt charts were the least-valued artifacts among agile teams.

Counterpoint

As interesting as Tate’s article is, the discussion in the comments is perhaps even more valuable. The comments vary from disagreement to nit-picking of points to agreement with the premise. There are some interesting ideas in the thread that end up augmenting Tate’s points, and also putting them in perspective (to prevent us from extrapolating).

• Do some, but not too much, up-front planning. A few people touch on this, in the context of architectural work. One suggestion is for an architectural sprint to start the project, based on Poppendieck’s work. In practice, we’re at least guilty of this (if you disagree) or proponents-by-example (if you agree). More importantly, we think the “strategic view” is best explored shallowly in terms of requirements, prior to prioritizing what should be done in detail in each iteration. However, this doesn’t suggest that Gannt charts should be used. A roadmap showing relative sequence, without trying to manage dependencies may be more effective.
• Emergent architecture versus planned architecture. One commenter points out that this is still a “dark art.” We would agree that making good architectural decisions before you know what you are building is much harder than after. But it gets back to an agile argument – you don’t actually know, even if you think you do at the time of planning what you are building. If we actually could know, then planned architecture would be better, and likely more efficient. But not necessarily more valuable. But to achieve that value, you need some understanding of the big picture. And a good approach to prioritization.
• People generally affirm that detailed insight into the distant future is impossible. That’s why we have rolling-wave planning. Time spent on the uncertain future is wasted. A high level view of the future is not uncertain – you are defining scope and value. A low-level plan is uncertain. Gannt charts don’t provide useful dependency information at a high level, and the information at a low-level, in the distant future, is worth less than the low-level-tasks it sequences.

Conclusion

Gannt charts for the immediate term have a very high effort to value ratio for agile projects. Generalists manage dependencies, and change them, continuously. Updating the chart isn’t updating a plan for action, it is updating a tally of the score (of things already done). Not adding much value here.

Gannt charts for the long term have almost no value for high level activities. Dependency information doesn’t make sense for high level stuff. Gannt charts for low level tasks in the long term are also suspect, because we fully expect that the low level tasks will change. And therefore, their dependencies will change. So the work is throw-away work. Even worse, it implies a sense of predictability, or at least creates a false precision about upcoming work.

In short, Gannt charts won’t help you plan an agile development project. At least not enough to justify the expense of creating them.

Imagine you have someone good enough to create a Gannt chart, and keep it current through the change. This superman is also tracking and communicating those changes and effectively managing stakeholder expectations. Now imagine what other valuable things you could have someone that good doing. Where do you really want them investing their time?

Why don’t more companies and teams use agile development techniques? We know some teams just aren’t aware of them – although that list is getting shorter every year. The benefits of iterative development over waterfall development are pretty well established. I don’t believe I’ve seen a study that shows that waterfall is more effective. Do people refuse to believe in the data? Or maybe they are unable to believe.

Inspiring This Article

Mishkin Berteig just wrote another article inspiring this one. He’s done it before, when talking about code debt and quality, and we’ve highlighted his article on the core elements of an agile approach. Generally speaking, you should just read his blog.

His most recent article talks about the non-negotiability of software quality when pressed for time. Although the comments thread seems to be going off on a tangent about the iron triangle of project negotiations (scope/content, cost, and time), the article is pushing a different idea. The idea that time already spent is a sunk cost.

The idea of sunk costs, also know as “don’t throw good money after bad” is difficult for most people at a psychological level. We often feel like making just a little more investment of time, work or cash will turn an ailing effort around. Unfortunately, a traditional waterfall or phased-based approach to project work increases the psychological pressure to continue working, even when the project is “bad”.

Mishkin Berteig

The point that Mishkin seems to be driving at is that by using an agile process, you dramatically reduce the sunk cost psychological issue. One thing Alan Cooper said about agile processes that really stuck with me is that agile processes are optimized to deal with change. His comment was in the context of a left-handed compliment, that agilists presume that change is inevitable because it is impossible to know in advance what needs to be done. That is an interesting debate, and even mentioning it here is likely to cause our discussion to go off on a tangent.

Taking those two ideas together – it makes sense that people who anticipate and plan for change will not incur a psychological penalty for changing their solution in response to changes in requirements. It makes for good support to Mishkin’s argument. Waterfall processes make change harder because of sunk costs. But there’s more.

Cognitive Dissonance

OK, now the picture of a brain scan might make more sense for this article.

Cognitive dissonance is a psychological term which describes the uncomfortable tension that may result from having two conflicting thoughts at the same time, or from engaging in behavior that conflicts with one’s beliefs.

Wikipedia

The reason that people feel uncomfortable about sunk costs is rational. Making decisions based on sunk costs is irrational. Here’s how cognitive dissonance can play out in a waterfall project:

1. We know we’re good at what we do. We gathered requirements and we’re implementing a solution based on those requirements – and we’ve developed a test plan to validate that we actually did what we set out to do. In short – we rock.
2. We’ve invested a lot of time implementing what we’ve done so far.
3. We’ve just been told that what the customer really needs is something else.
4. If we accept that the customer needs “something else”, then that means that we wasted a bunch of time and money doing the wrong thing. The delays (time is not negotiable – see Mishkin, we get it) may doom this product to failure even if we do fix it. This of course means that we are a lousy product team.

Cognitive dissonance is introduced between items 1 and 4 in the list above. We can not both rock and be lousy. These two ideas are mutually exclusive. In Mistakes Were Made, But Not By Me (linked in the ‘Recommended Reading’ box at the end of this article), Carol Tavris and Elliot Aronson describe this situation and its global ramifications in a way that will enlighten and frighten you. A quick quote from Dr Cathy Goodwin that sums up the central idea behind the book:

Why do people refuse to admit mistakes – so deeply that they transform their own brains? They’re not kidding themselves: they really believe what they have to believe to justify their original thought.

And that’s what we have here. Cognitive dissonance prevents people from accepting that change is important in a waterfall project, because they have conspicuously avoided change for the life of the project. It almost seems like they go out of their way to make sure that they don’t accidentally uncover changes until the project is complete. And the higher the waterfall, the more vested interest, the more likely it is that change is needed, and the greater the cognitive dissonance.

Cognitive Dissonance Prevents Adoption of Agile Development

Not only does the notion of cognitive dissonance explain why people freak out about sunk costs, but it explains why waterfall projects are so terrifically bad when they fail.

Now take this tactical assessment and apply it to the longer term.

1. We’re good at software development.
2. We run waterfall projects, we have check-gates, and other processes to assure that we get the job done right.
3. Sure, many of our projects fail. And maybe our “successes” are not as big as we initially planned them to be.
4. Agile development would make this better. The CHAOS report, many other companies, and many thought leaders in the space all seem to agree. We don’t do agile. We’re really not good at software development.

We’re introducing cognitive dissonance again. We can’t be good at software development if our process choice was the wrong one.

Catch and Release

There’s a catch to cognitive dissonance. And this is the striking part. It isn’t the case that rational people see the data and don’t like the conclusions to which it leads. Cognitive dissonance is a subconscious process. People are not aware. In an interview on NPR’s Science Friday podcast, Dr. Aronson referenced studies with brain scans that demonstrated the dissonance affect.

How big is this affect? In the podcast, Dr. Aronson refers to multiple cases where prosecutors discover that innocent people are incarcerated (and will continue to be incarcerated). They have, for example, DNA evidence that the convicted person could not have committed the crime. And those prosecutors would rather (subconsciously) let the innocent person rot in jail for the rest of his sentence than accept that he was wrongly convicted. That’s powerful stuff!

The pleasure centers of the brain of an affected individual are rewarded when they resolve the dissonance by ignoring or discounting the “conflicting idea.” We subvert the possibility of being wrong, at a subconscious level, and our brains reward us for it. That’s the catch.

So what do we do? Our only hope is to consciously accept the premise that our old ideas might be bad. That we might in fact, not be good at software development (or whatever). By making the change to acceptance of the new idea – and perhaps even experiencing contrition about it – we also will satisfy the pleasure centers of our brains. That’s the release.

Summary

Cognitive dissonance explains why people feel bad about sunk costs. The effect is amplified with waterfall processes.

Cognitive dissonance also exists as a barrier to adopting agile processes. People experience cognitive dissonance when exposed to data that what they’ve been doing with waterfall processes would be improved by changing to agile processes. These people resist changing how they run their projects as much as they resist the acknowledgment of changing needs during their projects.

Your project is almost finished. Last week, it was almost finished. And you suspect that next week, it will still be almost finished. Why does this happen, and what can you do about it? In some ways, we’ve known about this problem for almost 2500 years But the solutions are still far from widespread.

Zeno’s Paradox

The Greek philosopher, Zeno of Alea, posed a paradox, in the form of a race between Achilles and a tortoise. The tortoise won. And not like the tortoise and the hare – the lesson here is mathematical, not one of having good work ethics. The solution to Zeno’s paradox is found in infinite series mathematics. Here’s an easy to understand version of the paradox:

Zeno’s Paradox may be rephrased as follows. Suppose I wish to cross the room. First, of course, I must cover half the distance. Then, I must cover half the remaining distance. Then, I must cover half the remaining distance. Then I must cover half the remaining distance . . . and so on forever. The consequence is that I can never get to the other side of the room.

Prime Articles

As an engineer, frankly, I struggled with infinite series in college. Differential equations? Cake. Infinite Series? “Let them eat cake.” I struggled to overcome the notion that once you get close enough, you just take a step that is larger than the remaining fraction of the distance, and you’re done. There is an interesting parallel in project estimates, and therefore a point to this story.

Almost Completed Tasks

If you’ve ever been working on a deliverable, and thought to yourself, “I’m almost done,” then you’re halfway there. A day later, you find that you’re still “almost done.” And after that – still almost done. Have you ever depended upon someone to deliver something for you, to have them perpetually almost done? Like Achilles, some people simply lose out to the tortoise. But it isn’t a problem with the people, it’s a problem with how they are keeping track of their work. Or with how you’re asking them to keep track of their work.

Johanna Rothman writes about this exact issue.

Imagine you’re a project manager. You talk to your technical lead and ask how far along the team is. “Oh, we’re about 90 percent done,” he says. If you’re like most project managers, your heart sinks. You’ve been here before. Ninety percent done means the other 90 percent is left to do.

Eliminating the 90 Percent Done Game

We’ll look at one of the techniques Johanna identifies in her article – and as we talk about it, we’ll overlap several of her other suggestions.

Discrete Deliverables

Johanna offers several tips to address this issue – and one of them reminds me of my engineer’s solution – just take a step, and to heck with the halfway stuff. We sidestep the percent complete problem, by having people report a discrete status on a smaller amount of work. Then we roll those estimates up and describe “percent of the small tasks that are completed” instead of “percent of the nebulous task that has been completed.”

If people estimate tasks in large chunks (like weeks or months), then when you ask for updates, they can give you an arbitrary percentage complete. Johanna suggests having developers break up their larger tasks into daily tasks. In our experience, when building a detailed estimate from the bottom up, all of your tasks should be between 2 and 8 hours. If a task is shorter than 2 hours, you’re becoming inefficient – the time spent tracking the deliverable becomes too burdensome. And if the task is longer than 8 hours, then you really aren’t getting a way from the percent complete idea. This has been very effective for us in projects with both junior and senior people, and in projects with all sorts of deliverables.

Here’s the interesting part. Every contributor, working against a set of these 2 to 8 hour deliverables reports them as complete or incomplete – not with a percentage. Anything less than completely done is simply tracked as “not done.” Think of it as moving from an analog to a digital world. Instead of a week-long task like “Secure the website from hackers” you would create multiple tasks like “Whitelist all displays of user generated content” and “Implement SQL-Injection protection.” For a large site, you might have to break this down further, perhaps by areas of the site, etc.

Rolling these discrete estimates up gives you a top-level percentage complete. But by breaking it up into discrete deliverables that are independently complete or incomplete, you prevent the “almost there” problem. Eventually, there is only one step left – and you just take it.

Armed with this approach for task-tracking, you can become even more effective by using the burndown technique popularized in the scrum world for tracking projects. We’ve used this very effectively as a means to help new business analysts manage some large requirements deliverables on a high-profile project. The new analysts did not have experience in estimation of their tasks, and the project manager did not have confidence in, or visibility of their progress. By introducing burndown for managing requirements deliverables (use case and activity diagram development and validation), we simultaneously improved the ability of the team to communicate and estimate status.

Johanna also suggests using rolling wave planning to track these detailed level tasks. And this is important – the further you look into the future, the more changes there will be to the plan before you get to the future. And therefore the more likely that your planning work will be discarded, as you are asked to do something different. So only do the detailed planning one release out. Do higher level planning across all the releases. And then establish a process and expectations for how changes to the plan will be managed.

Summary

When people report the percentage complete of a single task, that estimate is suspect because of the hard-to-nail-down definition of almost done. When people report the completion of multiple tasks, we can then quantitatively add those up to provide a reliable percentage complete estimate of a set of tasks.

This approach provides for more reliable reporting, and a better feedback loop (helping the estimators get better at estimating). A side benefit is that the decomposition of large tasks forces or reinforces (depending on how you think about it) the act of decomposing larger tasks into smaller, actionable activities.

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value – they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.

Genesis

About a month ago, I read an article by Kelly Waters on how to prioritize intuitively. He presents a magic square diagram, showing both the “how valuable is it” and the “how hard is it to do” axes. I’m oversimplifying, read his article for more details – he incorporates elements of risk, complexity, etc. I really liked that he was addressing the “missing element” of how much work is involved. However, his diagrammatic approach, while presenting this information very well, does not really yield insights into what to do first. Kelly and I had a great discussion over the next couple weeks, exploring the interplay of work and value in prioritization, trying to find a way to encourage value-maximizing decisions.

Prioritize By Value

We have talked about prioritizing the most valuable requirements first repeatedly. And in the last of those links, we accidentally hinted at, but didn’t grasp the real goal:

We will only consider those steps where the profitability of change exceeds our hurdle rate for investment.

We’ve also talked in the past about using use cases as the basis for scheduling, as each use case represents realizable value. For the rest of this article, we’ll talk in the context of scheduling use cases across releases.

Consider a very simple example – you have five use cases, with values of 10, 9, 9, 8, and 7 respectively (the units don’t matter). If you sort those use cases in order by value, from left to right, they would look like the following:

The size of each box shows the relative value of having the use case implemented.

Based on our previous guidance (and everyone else’s), you would implement them in order, from left to right. Makes sense. Do the most valuable thing first. Do the next most valuable thing next. Repeat until the value is not high enough to continue.

What About The Amount of Work?

OK, the amount of work required should play a role too. In our time-boxing article, we describe each release as having a given capacity, which you can visualize in terms of cost (resource) and time (duration of applying resources):

We fill up that capacity with use cases, based upon how much work is involved.

We can estimate the work involved with each use case by any of a number of methods – but the earliest estimates can be developed using use case points.

Consider the following “work” measurements, identified for each of our use cases from above:

We have the same sequence of use case implementation (based on value), but now we can visually see that there are different amounts of work associated with each use case. The area of each box represents the relative level of effort required to implement the use case.

Prioritize By Value Results

The best way to explain the flaw with the classical “prioritize by value” approach is to show what happens after the first release. Consider that you can accomplish 30 units of work in the first release.

We can schedule the first two use cases for this release. The size of the time-box above represents the amount of work that can be accomplished. With the first two use cases scheduled, the time-box will look like the following:

We have completely used up the available capacity of the team (Work = W = 30 = 10 + 20) by delivering the two most valuable use cases. We have delivered 19 units of value (Value = V = 10 + 9 = 19).

Value Maximization

When we consider both the value (V) and the cost (in terms of work, W) of each use case, we see that some use cases generate more value per unit of work than other use cases. If we consider the ratios of value to work (V/W), and sort the use cases based on this approach, we would see the following:

And with the previous specific value and work values:

If we were to organize our delivery of use cases based on this ratio, we would be saying “prioritize the most effective use cases in terms of value per unit of work.” This may seem counter intuitive, but it makes sense – get the most bang for the buck earlier, and you will get more value faster.

Consider what our first release would look like:

We would complete three use cases (using 25 units of available work), and we would deliver 25 units of value. We would also be able to start working on one of the use cases that would be delivered in the next release.

True Maximization

To find the mathematically proven maximal value, we have to do a bunch more work. This prioritization exercise is actually an example of the bin-packing problem, an np-complete computer science puzzle. To make a long story short, we can’t use a simple heuristic and guarantee that in all cases it will be optimal. But we can do better than “most valuable first.”

If we use the scheduling rule as follows:

Schedule the use cases in order based on the highest value-to-work ratio, skipping use cases that are “too big” for the current release.

Then we will get value out of the system as fast as possible. There are a couple problems with this approach:

1. It does not take into account that you can apply work from one release to a use case that is scheduled in a future release. Intuitively, any “remaining time” after scheduling complete use cases should be spent on the next highest-ratio use case. I haven’t proven that mathematically, but it makes sense.
2. Use cases, and their underlying requirements, and the implementation tasks to support those requirements are not actually independent. You may need to introduce one use case before another – the second use case may not be possible without the first one. Implementing a requirement that is shared across use cases will reduce the “remaining work” for those other use cases – causing a need to recalculate ratios. Implementation tasks are often dependent upon one another. The discrete tasks to support a valuable use case may require implementation work that is also leveraged in lower value use cases. Further, some implementation tasks must be performed sequentially. You can’t optimize a query before defining a database schema, for example.

The second problem actually applies to any prioritization approach that incorporates value. The nature of software development introduces constraints (X must be completed before Y can be started). Those constraints narrow the possible scheduling choices. And they make it impractical to determine the “optimal” solution. At least with commercially available tools, excluding expert systems, which can be used to solve this type of problem.

Conclusion

• Sequencing use cases based solely on value does not maximize the delivery of value over time.
• Sequencing those use cases based upon the ratio of value to effort will increase the rate at which value is delivered to customers.
• It is impractical (and possibly marginally valuable) to determine the optimal sequence for scheduling use cases to maximize value.

You should use the “highest ratio first” approach, and when a use case can’t be delivered yet because of interdependencies, skip it. Also – apply judgement to sanity check if you are doing something that seems odd – like delaying a high ratio, high value use case. Explore with the development team if there are ways to adjust their dependencies to allow for a “more valuable” delivery sequence

You expect analysis to happen before design, and both to happen before implementation and testing. But how much should these activities be staggered? When a project is being run with monthly releases, it might seem logical to have each group working on a different release. For example, the test team working on the current release (3), the developers on the next release (4), and architects and analysts working on releases 5 and 6 respectively.

If your team is this staggered, you have a problem. It takes four months for a requirement to be released from the time the analyst has documented it.

The Pipelining Anti-Pattern

Mike Griffiths has an awesome article on the LeadingAnswers blog where he describes the Pipelining Anti-Pattern.

A pattern in the software world is a generalized description of a design, a solution, a process, or some other solution to a common problem. Patterns are intended to be re-used. Anti-patterns are the same thing – except they represent descriptions of common bad practices. An anti-pattern can be a very effective tool for describing a bad way to do something. It is especially effective when the anti-pattern is prevalent – most readers start out with “oh no – that’s what we do.” It also helps when the anti-pattern is followed with a prescription for a good way to address the common problem, after pointing out the weaknesses and flaws in the anti-pattern. Mike does a great job with this one.

Pipelining, or as one of Mike’s commenters calls it, full-pipelining, results in a project being managed as a series of tiny waterfalls – handing off “approved requirements” to yield “completed designs” followed by implementation, and ultimately by tests. If you want a more detailed understanding, and have been lucky enough to never live through this, now would be a good time to check out Mike’s article.

This can result in months of delay between when a need is identified and when it is satisfied. During those delays, requirements change. Teams focus on different releases. Switching gears to try and collaborate is both hard and expensive.

There has to be a better way.

Completely Insane Juggling

At the opposite extreme, everyone is working on the same thing at the same time. An analyst meets with users in the morning, gathers some requirements, and that afternoon the developers begin implementation and the test team starts defining the validation tests.

Also during the afternoon, the analyst discovers that the requirement was half-baked – he missed several pieces. He completes his analysis, writes it up and shares the changes with the rest of the team the next morning. The developers have to completely throw away the design and the work they’ve already done – so they start over.

By the next day, the analyst has discovered that there are bigger fish to fry – after reviewing his preliminary findings with the business sponsor, he concludes that there are other far more valuable goals to be addressing. By the time he gets those defined, the developers have already finished the lower-value implementation, and don’t have time to get the most important features into this release.

We’ve lost an important premise – that the most important things get built first. And we’ve got some serious inefficiencies, as team members are forced to discard work as their priorities and requirements change underneath them.

There has to be a better way.

Imagine driving on a cliff-side highway. On one side you have steep rock walls, and on the other, a long, quiet fall. You really need to avoid either extreme.

Finding a Middle Ground

Some staggering is required. There’s a reason that the pipelining anti-pattern ever came into existence. There are benefits to waiting until you know what to do before you start doing it. But if you wait too long, the cost of delays ends up exceeding the benefits of efficiency. At the same time, all of the roles on the team require collaboration – having people distinctly separated introduces the inefficiency of context switching. And taken to extremes, introduces unwarranted delays.

The main body of Mike’s article reads almost like an encouragement to go with the “fully synchronized” team. However, in the comments, there is some clarification and acknowledgment that having analysts run 1/4 to 1/2 iterations ahead of the rest of the team is a good balance in practice. We’ve seen that work effectively. We take an approach that is a little bit different, but nets out to about the same thing.

Synchronizing Activities

First, we look at synchronizing development and testing. Following a continuous integration methodology, we keep development and test in sync. Part of the development process must be testing of their code. While we may rely on a QA role to assure that the code addresses the needs, the developers must assure that the code does what they intend. That way, any issues that arise out of QA are issues of misinterpretation of the spec – not bad code. This helps avoid the dreaded code-freeze.

Second, QA can begin defining the requirements-validation tests as soon as there is a specification to validate. This happens in parallel with development. Test cases should be defined from use case scenarios. And use cases are implementation agnostic – so you don’t have to wait for the code to be completed. You need to know how the UI is designed to create test scripts, but not to create the test plan. So there may be a little lag in execution (of the test team, relative to the development team), but there is very significant overlap.

Third, we deal with the tough one – defining the spec. Mike sums this up as two activities – business modeling and analysis/requirements. His approach to exploring the tasks (versus the roles) really helps sidestep any turf wars – or at least sets the stage for rational discussion of the things that need to happen. We’ll keep this loose definition, and interpret it as follows: business modeling – determining what needs to be accomplished (definition of goals, prioritization, etc), analysis / requirements – defining user stories (or use cases) and the supporting requirements (or specifications).

Before development begins, you have to explore the breadth of the project at some level of depth, in order to both scope and prioritize. Many teams call this “iteration 0.” With that prioritization in place, modeling and analysis can begin in detail for the first release. This happens before the development team starts developing functionality. When the team members are started in parallel, this is a great time to get your test harness, source code control, and other operational infrastructure things in place. Developers can also use this time to get conversant in the domain, if they are not already.

This ultimately results in “just in time requirements”, with the development team as close behind as possible.

There is extensive collaboration with developers and testers during spec creation – helping to assure that what is being requested is both feasible and clearly understood. This collaboration also enables initial scoping to allow for scheduling of implementation tasks.

As soon as something is believed to be understood well enough, the development team can start. Our experience has been that this is usually a couple weeks after analysis begins – consistent with the “half a cycle” comments on Mike’s article. We manage changes to requirements based upon the complexity of the proposed change. If a change is too large, or the release too close, the change gets incorporated into the next release. There are a couple benefits to this approach. First, expectations are set with developers, so that they aren’t pressured in a way that might jeopardize quality for a given release. Second, expectations are maintained with customers, so that their expectations of what is delivered in a particular release are managed effectively.

My personal experience is that this is more effective, results in faster response to change, and when presented professionally, results in higher levels of customer satisfaction than “drop everything change it now” approaches.

What about UX?

We’ve been talking in terms of requirements, but the same general approach applies to user experience efforts. Initial ethnographic studies and branding (layout, look and feel, IA, internal standards) work can be started in iteration 0, with mockups, prototype development, usability studies (at varying degrees of fidelity) happening in parallel with specification development. And like spec-development, this involves collaboration both with users and developers.

When you plan a release, agile user stories, or classic use cases are the best sized pieces to use in the planning – from the perspective of your customers. Each user story can be further decomposed into a set of specifications, and those into development tasks. Development tasks are the right sized unit to manage your work breakdown structure – communicating the release schedule internally with your development team.

Overview of Structure

Even agile projects benefit from having a structured perspective on why and how to develop the software.

• Customers have goals, and those goals have value.
• Those goals are achieved through user stories (or use cases).
• Capabilities, usually defined in a specification, enable people to execute the stories.
• Development tasks represent the work that must be done to implement those capabilities.
• Tests can be defined to validate the capabilities, and assure that code is working as-designed.

Scheduling Releases

We’ve written before about communicating a release schedule with use cases. The fundamental concept is that you need to deliver actionable, valuable capabilities with each release. Since customers get value from goals by executing use cases, you need to deliver a complete use case (or user story) for the customer to get value from it. This also helps with the “why do I care about release X?” question – because it provides value.

Although your customers don’t need to know which development tasks are included in what release, your team does. And as a point of clarification, when you are scheduling the work that fits in the time box for a release, you absolutely can schedule tasks that do not add up to a complete use case. Sometimes all of the work required to implement a single use case can’t fit within a single time box. And there’s no particular benefit to trying to force it to always happen that way. It is more important to schedule the most valuable use cases (or user stories) first. And then communicate to your customers the releases in which those use cases are completed.

Nine Development Team Benefits

Doug Blis, at Visionpace, just wrote a good article listing nine reasons to divide user stories into tasks. He provides a couple of paragraphs of detail on each of the following reasons:

1. Iteration Planning
2. Iteration Burndown
3. Accountability
4. Shared & Individual Learning
5. Tasks Encourage Better Design
6. Forecasting Velocity
7. Tasks Serve as Reminders
8. Talk to the Dog
9. What if you hear “can’t/won’t task?”

These are all excellent how do we improve as a development team benefits. Managing your development team’s efforts at the task level provides enough data-points to improve, without being so much work that it hinders. Tasks are also the perfect size for extrapolation and improved estimation on future projects.

Getting Bigger Picture Benefits

In addition to your development team getting better by using tasks, you can improve your overall software delivery process. The key is to be able to clearly define the traceability for the project. Traceability won’t really help the development team get better at developing (which may be why not many agile proponents talk about it). But it will help you manage your project, and therefore the release schedule for your product. And that allows you to improve your relationships with your customers.

Better forecasting of tasks (combined with traceability) yields better forecasting of capabilities. And this also leads to better forecasting of user stories (or use cases). This allows you to spend less time dealing with changes to the schedule – and more time focusing on finding huge value for your customers. And fewer schedule changes result in better relationships, more trust, and higher profit (when you can leverage that trust into higher prices, and when you avoid the costs of schedule changes).
Do it so your development team gets better. And do it so you deliver better products, and build better relationships.

But sometimes, it happens anyway.

The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.

CPMs Question

1) What’s your favorite PM breakdancing move for telling (or avoiding telling) an important customer that his favorite feature is not planned for any of the next 3 releases?

2) What about for telling the same thing to a sales droid who claims a multi-gazillion dollar deal is going down the toilet because you don’t have Feature X?

Cranky PM, in Share Your Secret Moves

Several Answers

The readers of that article really stepped up with nine responses. Check out CPM’s article for the details – but here is a summary of the answers. Some of these are bad ideas, and some are good. Usually, the bad ones were written as “I used to…” Our thoughts about each are also included in the list.

• [Bad] Wait until the last minute, then deliver the bad news. We agree – about the only way to lose credibility faster would be to not admit the feature was missing until after the release, when the customer calls to ask.
• [Good] Tell the customer that the scope and priorities have been updated, as soon as the decision has been made. This builds on, or at least sustains a cooperative trust-based relationship.
• [Other] When a customer has multiple features slated for a release, ask them to prioritize them, and try and include them in priority order. This should be happening anyway, before finalizing the schedule – but if it hasn’t already happened, it definitely should happen when the realization occurs.
• [Other] Think outside the box – outsource to get the to-be-missed features included anyway. Deal with the integration hassles internally. This can be good or bad, depending on both your team and the partner.
• [Bad] Re-characterize the release as a “get the basics in place” release, explaining that the to-be-missed features need to come after the basics. There is some validity to the logic behind this (that you can’t really know what you need in detail until you start using the application). But to suddenly discover this after having already committed to a schedule is not good.
• [Good] Restructure the release schedule and add a “next” release to include the to-be-missed features. This is one of the tactics we identify when over-filling a time box.
• [Good] Don’t make promises you aren’t sure you can keep. This is a preventative solution – set expectations appropriately, don’t make promises of content until you near the release. If you’re using iterative development, for example, you might be creating a build every month. You may only be releasing once a quarter to your customer. If you are using continuous integration, and testing effectively, you know you can avoid regression bugs – so you know you can release all of the features from the previous interim builds. Let the customer know that those features have been completed. You’re reducing (perceived) risk for the customer – only the last (and ideally, lowest value) features are still undecided.
• [Funny] If the feature is for sales bigwigs, you’re fired. If the sales person has less clout, make them follow procedure (justify the business value and document it, etc…).
• [Good] Challenge the premise that a sale is dependent upon feature X. Push back on or work with the sales folks to identify the true requirements – not the proposed solution. From what I’ve seen of enterprise software, sales are made based on relationships, not features – and not even price.
• [Other] Distract the customer by emphasizing all of the stuff that is important to them that will be in the release. Softens the blow. Done well, this can really work. If you are implementing the most important stuff (to the market) first, the odds are that it is also the most important to this customer. And by the reverse, the better aligned this customer is to your market, the less effort you are spending on “one-off” customizations. So this redirection technique, when you’re doing everything else right, could also be classified as “put it in perspective for the customer.” When you do that – this is definitely good. If, on the other hand, your priorities are messed up, this can be a bad thing.
• [Bad] Make the excuse that the feature slipped because of “security enhancements” (or other ‘sounds more important’) taking priority at the last minute. If this is true, then this is just an example of ‘more important stuff is slipping’ – if it is false, it is lying. Again – the ‘rabbit out of a hat’ thing should not happen in a positive relationship. Maybe this is an ethical gray area for some folks, but we choose not to take this approach.
• [Good] Share the product road map regularly with customers. Use the road map as an artifact to set delivery expectations. That practice is a good one, and is effective in working with sales droids. It doesn’t help with to-be-missed features, however.
• [Good] De-value the feature request and focus on the benefit request. Another good one for the feature-X request. Work with sales to identify the reason why behind the feature. Then incorporate a solution into the product plan.

Really some great answers. How do we mix these into a recipe for success?

Success Recipe

Unfortunately, fire-fighting seems to get more attention than fire-prevention. We tend to get rewarded more for fixing problems than preventing them. This of course leads us to get better at extinguishing fires than avoiding them. But a good software product success strategy is built on fire-prevention, with some contingency plans.

Do the following to prevent problems:

• Prioritize goals (aka needs or problems) based on market value. This is the strategic, multi-customer view of your product.
• Communicate release schedules based on the use cases that enable your customers to achieve those goals. Note that you may be scheduling improving versions of the same use case.
• Share that schedule with your customers. Since you should be continuously refining this plan, you should also be continuously sharing it. Use this road map in discussions with sales folks.
• Make sure that the release dates are not arbitrary. If you’re releasing regularly (monthly, for example) – this is less of an issue.
• Establish expectations that your sales-support activities are market-focused, multi-customer activities.
• When a sales person approaches you with feature X, work to uncover problem X and then assess and prioritize it for the market relative to everything else. There are limits to how quickly you can include it in the development schedule without being disruptive. If you need to be disruptive, make sure it is justified.

And when you do have to slip something from the current release:

• Let the customer(s) who are really dependent upon it know as soon as you suspect.
• Keep them appraised as you make progress (or lose ground). Think of the status report you might give to your manager about a project’s status. Well, you really work for the customers, right? Let them know.
• Put things in context. When you slip something, it better be the lowest priority item. And if your customer’s individual needs are aligned with the overall market needs, this is easier to deal with. When the customer does not represent the market, you have to determine what expenses you are willing to absorb to service the customer. Not every sale is a good one – especially if one customer detracts from your ability to sell to multiple customers, or pulls you away from your strategy.

Another form of slippage is when you re-prioritize future features. Now you’re saying “here are the changes to the roadmap.” The same tell people right away, focus on strategic value, and put things in context ideas still work the best here.

Jonathan Babcock has written a couple interesting articles on preparing for a review meeting. He touches on a couple generic “good ideas” and explores one critical idea in more detail. We focus on that detail – helping participants be prepared to participate – in this article. His articles, and this topic in general are useful to anyone who runs meetings that require participation from attendees – business analysts, product managers, and project managers, for example.

Meeting Planning Articles

We’ve created a bundle of articles at nexus about how to plan and run effective meetings. The bundle includes both of Jonathan’s articles, as well as one of our own on making meetings more effective and a Business Week article on how Google runs meetings.

The bundle is open for collaboration, so other nexus users may add other articles on the topic. You don’t have to be a registered user at nexus to read the articles, so click on over and check them out. Then take a couple minutes to register and rate or review the articles – because the seconds you spend vetting these articles will save others minutes when they are researching in the future.

Summarizing the Main Prep-Points

Jonathan’s main prep points include

• Distributing the material early enough for participants to review and provide feedback
• Circulating an agenda in advance
• Reserve the meeting room & equipment
• Request confirmation of attendance or delegation where appropriate

The other articles include the following prep points

• Defining the goals and deliverables of the meeting up front to set expectations
• Assigning a note-taker or scribe for the meeting

Unprepared Participants

Jonathan raises an interesting issue – when, in spite of your prep work, people fail to prepare for the meeting, what should you do? This is a tough one. If you start with the assumption that only people who need to be in the meeting are actually invited to the meeting, this issue becomes critically important. In many organizations, too many people attend meetings. They are certainly wasting their own time, and often end up wasting everyone’s time. If you are culturally obligated to invite superfluous people to the meetings, that’s unfortunate, but don’t worry about making sure they are prepared. Focus on the people who need to be there and be prepared.

Jonathan writes his advice specifically for requirements specification review meetings – where people’s input is critically important. The issues and advice apply to any of a number of collaborative or approval meetings. They can be generally described as meetings where multiple people need the information, should provide input, and ultimately must agree on the outcome of the meeting.

Don’t Do This

Sometimes you, and everyone else in the meeting needs to take the efficiency hit of dragging along the folks who didn’t do their homework. If you have to, you have to. After the meeting, talk privately with the person who let everyone down, and work together to prevent it from happening in the future.

Don’t attack the person publicly in the meeting. Don’t slam your notebook closed and declare the meeting to be over because someone had something more important to do. That would be just as unprofessional as it was to discover that people were unprepared for the meeting. Maybe that person did have something more important to do. The problem truly isn’t that they were unprepared, the problem is that you didn’t know about it in advance, and couldn’t respond appropriately.

That’s the crux of the issue, and the reason that Jonathan’s advice is good.

Do This Instead

Touch base with the attendees before the meeting. Make sure that everyone who needs to be prepared is prepared. If someone needs to bring materials, make sure they have them ready to go. Work with them to get them completed if you need to. Reschedule the meeting if you need to. Carry on with the meeting, and deal with the missing contributions if that is what is appropriate. You can’t do everyone’s job for them – but you can do your job for everyone. The meeting attendees are implicitly relying upon you to not waste their time. And since it is your meeting, if someone you are relying upon is failing to deliver, it is your responsibility to adapt.

Jonathan offers a couple suggestions to get attendees to prepare for the meeting. His first suggestion is to get their inputs so that you can incorporate them into the agenda. This is a good approach, because it helps attendees develop a sense of ownership in the agenda. Even if they don’t modify the agenda, they are taking some ownership in what you have put together by acknowledging and accepting it.

Jonathan also suggests letting attendees know that you will cancel or reschedule the meeting if you don’t have their inputs a day or two in advance of the meeting. We would approach this with a slightly lighter touch, but we like the base idea. When there are inputs that would crater the meeting if they were absent, work with the contributors to assure that they will have those inputs ready. If they can’t get them done in time, work with them to reschedule the meeting (before the meeting begins) so that you can carry out the meeting with their inputs.

Often, meetings get derailed when people who are “too busy” are simply not conversant with the material to be covered. They don’t have the background they need, or a deep enough understanding to be effective in the meeting. The classic example is a decision maker who needs to know the context for making decisions. When everyone else in the meeting has the context, you’re wasting their time getting the decision maker up to speed during the meeting. Work with that attendee to find a time to help them review before the meeting, or reschedule the meeting, or ask them not to attend it at all. If you have a one hour meeting with seven people, you’re wasting six hours (across the team) by going over the material again to get the laggard up to speed. Wouldn’t it be better to spend two hours in a one-on-one with that person before the group gets together?

To quote Jonathan:

Worst of all, whether it’s completely fair or not, the productivity of a Business Analyst’s meetings are seen as a direct reflection on the his/her organizational and interpersonal skills.

Other Approaches

Craig Brown offers a couple tips in the comments on Jonathan’s second article. He suggests meeting with the leaders in advance of the meeting, and also providing them with printed versions of the materials before the meeting. Craig suggests letting the leaders know that you will collect their “marked up” versions of the documents [before] the meeting. I’ve seen this be very effective with upper managers and decision makers. There’s something about marking up a print-out that engages these folks.

Maybe they are less comfortable with electronic documents (although that is becoming less true every day, and varies from company to company). I suspect that marking up a paper copy allows someone to “scan” more effectively, cross-reference with other documents, and put things in context better. Often the “decision makers” are in a unique position of having fewer details and more context. Giving them an alternative medium for reviewing the docs may help them to put things in perspective more effectively.

What approaches would you suggest?

To define the boundaries for our agile project, we need to define the scope. To provide a guiding framework for the rest of the work, we need to document the vision. We could create heavy-weight scope documents and vision documents. And we could run them through reviews and get approvals and wordsmith them to death.

But we won’t. Agile processes are about documenting enough, not documenting for the sake of documenting. This is a small project with an even smaller team (one person right now – but that will grow as people start helping out). An informal documentation style will be sufficient. The key element is to have something referenceable and mutable. If we can’t change the scope or the vision based on market feedback, we aren’t being agile.

These two project management artifacts seem logical to combine into a single article

Vision Document

Create a site that allows people in our niche to help each other find great articles, regardless of who wrote them. People will identify and evaluate (rate/review/score) articles on their merits. People will also categorize (taxonomy/folksonomy) the articles to make it easier for others to find documents that they are looking for at that time. When a person is searching in our space for an article, it is either as a beginner or an expert (on that subtopic). This site should help people filter to look for articles appropriate for the type of search they are doing at that time.

[Update 26 Apr 2007: We've updated the vision for the project - the update is included below]

Using the language described in Gene Smith’s Social Software Building Blocks (http://nform.ca/publications/social-software-building-block), we want to focus on sharing and reputation, while incorporating elements of identity, conversations, and relationships. We do not want to focus features on groups or presence. The diagram for our site would therefore look like the following:

Scope

In this project, we talk a lot about “our space” and “our niche.” Our niche is intended to be articles about:

• product management
• business analysis
• requirements definition and management
• business rule definition and management
• business process modeling
• agile processes
• interaction design

In terms of functionality, our scope is limited to improving everyone’s ability to find great content in our niche. That might mean making it easy for authors to tell people about articles, but more intentional is the ability for people to highlight great articles for each other. The scope is not intended to provide a mechanism for people to content. People should be able to indicate some assessment of the content – not just an unadorned link to the content. That may mean ratings, reviews, comments, thumbs up/down, etc.

In terms of deployment, this project will be a “self contained website” that is intended to be deployed into a subfolder at Tyner Blain ( http://tynerblain.com/folder/ ). We may elect to deploy it somewhere else (like a subdomain, or a separate TLD).

Leading Answers, an agile project management blog, has a great article that details some agile techniques for release planning exercises.  Their article includes explanations and great diagrams.  Check it out.

We haven’t done any of these particular exercises, but really liked the article and ideas.  Especially the transition from the “Remember the Future” exercise to the “Shape the Product Tree” exercise.

Anyone tried these agile release planning techniques before?  Have any success or horror stories?