How We Do Things – Planning Part 2

This content comes solely from my experience, study, and a lot of trial and error (mostly error). I make no claims stating that which works for me will work for you. As with all things, your mileage may vary, and you will need to apply all knowledge through the filter of your context in order to strain out the good parts for you. Also, feel free to call BS on anything I say. I write this as much for me to learn as for you.

This is part 3 of the How We Do Things series.

In the last post I talked about the various evolutions of planning the team has been through over the last few years. This post is about what we do now. Take a moment to read the last one to catch up on what the picture below is about.

The Planning Space-Time Continuum


The basic gist here is that as items move from right to left they become more well-known, more defined, and more likely to actually be worked on.

JIT Planning Next Work To Be Done

We’ve come to a point where we plan, basically, as much work as we need to plan to keep work in progress until the next time we want to plan. I’ll try to make that a little less esoteric.

We intend to plan a week’s worth of work at a time, give or take. The acceptable threshold is typically anywhere between 3 days and 8. Usually this takes the form of planning just one or two minimal marketable features (MMFs – more on these in another post) depending on size. There’s a lot of “feel” to this, and that feel stems from having established a pretty rhythmic workflow and from having same(ish)-sized stories (more on that in another post as well).

Mechanically, the planning meeting looks like this: representative team members (usually myself, one or more BAs, the developers that will work on the MMFs, and a QA person) will get together and go through the stories that need to get worked on next. We’ll do a story workshop of sorts where we flesh out details of acceptance criteria, surface any issues or further questions, actually plan out some tests, and determine if the stories are appropriately sized.

If any questions or blocking issues come up at this time we will deal with them then and there by either talking them out, or if necessary tracking down the right people to answer the questions. If we can’t get the answers right away we figure out if we can get started without them and trust that someone will have the answer by the time we get to that point. This will spin up a thread for a BA or myself to go track someone down in the lab or elsewhere in the organization, set up a meeting, and do that whole thing.

This planning is unscheduled and happens as needed. If we are running low on work today, we’ll schedule a planning meeting for tomorrow morning. They usually last no more than 30 minutes unless there’s a lot of design discussion to be had.

Near-Term Planning – The Rolling Wave


The planning in the prior section is directly seeded by the planning done in this section. This is the next segment of the continuum to the right, and represents the picture of what we will probably be working on sometime in the next month.

This stage of planning doesn’t directly involve any developers or testers unless specific questions arise. At this point the BAs and I are sketching out the stories at a higher, not quite as detailed level, and stitching them together to form MMFs. We are figuring out what questions need to be asked and where these MMFs will fall in the slightly larger picture. Here is where we are evaluating priorities of features and roughly determining when they will be started. In short, we have about a month’s worth of stories, give or take, in states somewhere between fine and coarse-grained detail, with priorities, and we’re fairly confident that we will get to them in the next month. This is what a scrum team might call their product backlog.

This planning happens on a schedule every Monday morning. We go through requests, evaluate them, evaluate work in progress, and determine which stories to add finer detail to and queue up for the next work planning session.

This is a variation of Rolling Wave planning in that we don’t necessarily keep the “wave” the same size at all times, and we don’t make detailed work plans for the items in the wave. There’s also no guarantee that items move linearly from the end of the wave toward the beginning as time passes, since we allow for priority shifts within this space. In some ways, it’s more like a rolling cloud than a rolling wave, but I don’t know if I’m qualified to make up a new project management term.

Some weeks, like this week, we may not bring any new stories into the wave at all. We may sit down, go through the backlog, look at work in progress, evaluate current conditions, and determine that we don’t need to spend any time adding more work to the wave. To me, this is perfectly acceptable in the spirit of eliminating waste. We aren’t adding more inventory when we don’t need it, and we aren’t wasting motion defining things when there’s no immediate requirement. Sometimes our wave can get as lean as to only have a week or two in it, and sometimes it can bloat up to 6 to 8 weeks. We use this wave as our buffer to adapt to changing conditions.

There’s a real chance that the work put into the wave last week will be superseded in priority by new work identified this week. We don’t push that other work out just because the priority changed, we just insert the higher priority stuff where it belongs. This accounts for the occasional bloating of the wave, and we compensate by not adding to it next time.

Sometimes there is no priority work to be brought into the wave, or no stories that we can get enough information on yet, so we just let it go for that week and let it shrink in size. If you’ll pardon the metaphor, we let the size of this backlog ebb and flow fluidly.

The picture of the wave at any given time allows us to make decisions about what work will be delayed if new priority work is identified, and we can share that easily with project stakeholders. Because we know that we’re talking about a month or so of work, we are able to make statements about timelines of work that has been specified in enough detail and given enough priority to be in the wave. This makes external parties much happier.

The Roadmap

good_luck_sign.jpgThe sections farthest to the right are our next quarter/next year roadmap. This is where we would understand longer-running strategic initiatives or targets that we will ideally get to if, and only if, current conditions remain the same. This includes items from both the corporate initiatives roadmap, and our internal project roadmap. This could be anything from “In Q4 we are likely going to introduce a new product line” to “we’d really like to replace our hand-rolled data access with NHibernate.” We put this stuff on the roadmap to serve as the mile markers for where we (the organization, not just the developers) want to take our software.

Some items on the roadmap will very likely get implemented, and we may know it well in advance, but their priority or maybe external dependencies aren’t such that we could reliably be planning this work yet, so it goes out here to the right for the time being.

Some of the items on the roadmap could very well never get implemented. These aren’t just the “man it would be great if…” items, though those are on there. They are also the items that are totally valid, have strategic value, but somehow never seem to win the priority battle with other items. These are the items that usually end up becoming factors in the decision to increase staff or potentially purchase something.

Or maybe they are items that get totally replaced by something better. As an example, we had a project out here in this space for almost two years. Everyone wanted to do it. The business was hyped on it. They kept asking when we could get to it, and kept insisting it was going to be a key part of our service offerings. However, it never could beat out other priorities. In two years it never once won a priority battle. Recently we uncovered a vendor that would provide us with a 90% solution that would take mere weeks to integrate, versus what was looking like a multi-month project. The original target came off the list, replaced by the new hotness.

If we had spent any real time planning this project beyond a very basic understanding of its scope and keeping it as sort of an ‘idea bucket’ that work would have been completely wasted. As it stands, no harm no foul.

The Lie

The last part of the continuum I want to address is what we have affectionately dubbed “The Lie”. This is the point past which any projections you make on time/cost/when/where/who/how something will get done may as well have come from a magic 8 ball. When asked for this type of long-long-range (usually this is somewhere in the neighborhood of 6 months from now for us) information, we play it straight up. We say “this is a lie. what we are about to say will not come true at all.” For some reason we can get stakeholders to accept and understand that it’s a lie, but we cannot get them to stop asking for the lie. It boggles the mind. But whatever. We’re up front about it, and we refuse to be held to it. Part of effective planning is identifying the issues and constraints that will make the plan go astray, presenting those, and sticking to your guns when they happen.

As a side note, I want to point out that these time thresholds we have come up with have been a moving target, and yours will differ based on the size of your team, how fast they work, the nature of your organization, and a ton of other factors. So just be prepared to experiment.

Technorati Tags:
, , , , , , ,

About Scott Reynolds

Scott C. Reynolds is a developer with over a decade of experience creating enterprise solutions, primarily in healthcare and biotechnology. He is passionate about the art and craft of applying software solutions to business problems. He is a frequent speaker and participant of community events nationwide.
This entry was posted in how we do it, lean, management, software, team. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to How We Do Things – Planning Part 2

  1. Mihai Lazar says:

    This is nice. Thanks for sharing. You’ve given me something to think about, maybe the work process will stick with me, maybe not but it is something I found useful.

  2. alberto says:

    In Scrum, a product backlog can very well fit all your planned features, not only your rolling wave. Nothing in it says all stories in the product backlog have to be fine grained, so you can (and should) also add your roadmap and “lie” features in it.

  3. @alberto

    the roadmap and lie features are not “planned”. They just “exist”

    What we found was that maintaining a single backlog for everything became noisy and involved a lot of wasted motion. Things far into the future detract from the signal of managing work coming up.

    Additionally, and I could be wrong, but my understanding of the scrum backlog is that it is a prioritized backlog. Things far into the future here do not have priorities attached, further lessening the usefulness of keeping them in the same grouping as the rolling wave.

    but again, this is just what I do.

  4. mob says:

    Nice series, thanks for sharing all of this.

    BTW, I keep thinking that a midi of Montell Jordan’s “This is how we do it” will start playing when I open these posts. :)

  5. alberto says:

    Well, when I said planned I was referring to things the client “wanted to have”, just as you called it the “planning space-time continuum”. They don’t have to be planned in detail.

    And yes, the backlog has to be prioritized, but IMHO it’s no different from your different segments: high priorities first, low priorities last, and a continuum in the middle.

  6. @alberto sure, it’s a matter of perspective. for us it’s about reducing noise and extra movement. Things we know don’t even need consideration for 6 months don’t even enter our minds when we look at the backlog.

  7. How we do things planning part 2.. Awesome :)