jonm.dev

The Art of Writing Software

Scrum thoughts: Pre-planning

Series [ Scrum Thoughts ] Tags [ planning poker, pre-planning, Scrum, Scrum planning session, Scrum pre-planning, Scrum story planning, sprint pre-planning, story points, user stories ]

I think the way I’ll go about my scrum discussion is to go through the order of battle for one of our sprints, at least from my point of view as a software engineer/tech lead.

We usually kick off a sprint with a pre-planning session that happens before the formal Sprint planning session. In this session, we walk through a list of asks from our product team (who come prepared with a big whopping list of them off the product backlog), put LOE (level of effort) estimates on them, and then help distribute them across the multiple scrum teams we have dedicated to the product.

We’ve been capturing the features on index cards in what we call “user stories” for convenience, even though they are not written in the usual “As a user, I want X so that I can do Y” format. I’ll continue to call them user stories here, since that’s what we call them, but you should mentally substitute “feature name” here instead.

Now, we are still essentially working in a waterfall methodology, and just running scrum within the development portion (I really dislike this, and think it’s inefficient, by the way), so a lot of the feature requests are “implement page X to spec”, where we get an IA wireframe and some designs handed down as the definition of the feature.

So now we have some senior engineers representing all the development teams provide a high-level estimate. We use story-point estimation for this, and play “Planning Poker” using estimates of 0, 1⁄2, 1, 2, 3, 5, 8, or 13 (so we go for an order of magnitude). We sometimes get into the weeds here but are getting better at quickly arriving at a common estimate. I’d say most of the engineers that participate here are roughly equally productive, and we have a rough rule of thumb that says one story point is about two developer days for us. YMMV.

So we write the story point (SP) estimates on the user story index cards, and then the product folks prioritize them. We actually stick the index cards up on the wall and then the product team rearranges them in priority order while the engineers tag them to indicate which team would likely tackle each one (according to which subsystems those teams have expertise in).

Now, given our past SP velocities, we can guess where the “fold” is likely to be – how many of the features are we likely to actually be able to get done. We also, thanks to the team tagging, can juggle some of the tasks around to balance out the workload for the teams (especially for tasks where multiple teams could take them on). The product team may also juggle some of the lower priority items around to move things back and forth across the fold (there’s nothing like saying “You probably won’t get this feature this month” to see how important a feature really is!).

When we’re done, we have a global priority on the user stories, and know which user stories we’re going to present to each team for planning on the next day, and take down the index cards so each team can have their stack to plan with.

Analysis

Pros.

  1. Story point estimation with historical story point velocity measurement is surprisingly accurate. When we do the actual down-and-dirty sprint planning, we end up pretty close to the same set of tasks.
  2. Putting the user stories on index cards and taping them to the wall lets multiple product folks work on the prioritization in parallel, while the engineering folks can work on the team-tagging in parallel. It’s also much easier to reprioritize on the wall than it is in a spreadsheet!

Cons.

  1. This is time consuming as heck. We usally spend 4-5 hours doing this for a one month sprint with about 10-12 total development resources. It is emotionally (from arguing over SP estimates) and mentally (from the length) draining.
  2. Due to the nature of our user stories, we have to actually look at wireframes in minute detail to grok the nature and complexity of a task to put an SP estimate on it. This usually means this has to be gone over twice – once in the pre-planning meeting, and then once again in the actual sprint planning meeting. This is a direct result of having fully-spec’ed wireframes come down from on high. For example, it would actually be quicker to estimate a story like “As an editor, I would like to have a page where I can drive the content” versus one which is “As a product owner, I would like you to implement the vision of an editorial page as conceived by our design and IA teams”. Especially if the design and IA teams have decided to put some complicated (to implement) features in there.