Jeremy Jarrell

Agile Made Simple

Tag: release planning

Help! My Team Keeps Missing Releases

Lately, I’ve seen a recurring anti-pattern across several different scrum teams.  The pattern works likes this: a team forecasts a certain number of points per sprint and regularly completes that same number.  If…

Lately, I've seen a recurring anti-pattern across several different scrum teams.  The pattern works likes this: a team forecasts a certain number of points per sprint and regularly completes that same number.  If you were to plot the team's hit rate, or number of points completed over those forecasted, then you would see a fairly straight line at 100%.  The plot below represents a team who, after an erratic first few sprints, has settled down to a particular 100% hit rate.

Hit Rate From the outside, it looks like the team is right on track.  But, as they begin to near the end of the release, everyone starts to realize that the picture isn't quite as rosy as first thought.  In fact, it becomes obvious that they're not on track at all to complete all planned work in time for the release, even though they had consistently completed the same number of points they had forecasted.  How does this happen?

Finding the Churn

This can occur when the team regularly accepts new work during the sprint that pushes the planned work to the side.  This work, which often takes the form of high priority bugs or customer issues in production that must be fixed immediately, is estimated and added to the sprint alongside the existing work.  Often, this “high priority” work pushes the previously scheduled work to the side.  At the end of the sprint the team celebrates completing the right number of points…unaware that they actually completed the wrong points.

How can we catch this before we near the end of the release so we can do something about it?  By tracking “point churn”.  Churn is the number of points added to a sprint after it has begun.  Typically, we discourage adding work to an in progress sprint but some teams follow this practice to handle high priority work that must be addressed quickly.  These teams can get early insight into their churn by plotting the number of points added to their sprint alongside their hit rate.

Hit Rate with Point ChurnThe plot to the right adds an additional line along side hit rate to indicate point churn.  The red line, bound to the right axis, represents the number of unplanned points added each sprint.  You can see that although the team maintains its 100% hit rate, more and more points have been added each sprint.  This could be an indicator that although the team is completing the right number of points each sprint…they could actually be completing the wrong points.

If you notice that your hit rate is consistently around 100% but your churn is regularly above 0 then this is can be an indicator that you're falling behind in your overall release, even though you're completing the planned number of points each sprint.

A Simpler Approach

But there is another approach.  Rather than go to the effort to track unplanned work that is added to each sprint, an alternative approach is for the team to still accept the unplanned work but not award any points to it.  In this model the work is not added to the sprint, but it is still tackled alongside sprint work.  This approach is easier since it doesn't require tracking additional points and, if the team reaches the end of the sprint and still has planned work outstanding as a result of being distracted by the unplanned work, then the hit rate for the sprint actually provides a more accurate reflection of how the team is likely to pace for the overall release.

To make new work more visible in this approach you can even add an additional lane to your sprint board for it to flow through.  Seeing this work alongside your planned work, especially with team members assigned to it and Work in Progress limits respected, is a wonderfully effective way to illustrate the impact that new additions can have on your sprint plan.

Scrum Board with Firelane

In the image above, we've added an empty row to the bottom of the standard scrum board to allow unplanned work to flow across the board.  These cards are red to indicate their importance.  However, note the WIP limits for each state called out in parenthesis at the top.  Deploying has a WIP limit of 1 meaning, that the unplanned work is currently blocking release of the planned work for the sprint.  Adding an explicit lane to the scrum board can more visibly call out the effect that unplanned work has on a team's productivity rather than the team simply accepting the work but then quietly falling behind.

Whichever approach you choose, asking whether your team is completing the right points instead of just all of the points can provide early insight into your team's pace and give you the opportunity to correct your course before its too late.

Are you new to the Scrum Master role and are just trying to find your way? Or, are you an experienced Scrum Master who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Help! My Team Keeps Missing Releases

Release Planning from the Top Down

Quick…what was the killer feature in your last big release?  If your release is like most then you’ll probably have trouble answering that question.  In fact, if your release is like most…

Quick…what was the killer feature in your last big release?  If your release is like most then you'll probably have trouble answering that question.  In fact, if your release is like most it was probably filled with a grab bag of low quality features and a handful of bug fixes.  Sure, there may have been one or two important features in there, but for the most part they were buried amongst an avalanche of noise.

Bottom-Up Release Planning

Bottom Up Release PlanningWe call this type of release planning Bottom Up Release Planning.  It often begins with simply combing the backlog for stories that need to be released and grabbing as many as you can fit in your next release.

Sure, there are advantages to this, most notably that it's easy to do.  Release planning tends to be simpler and take less time using this method.  In fact, you've probably seen these types of releases before, they often begin with a “wishlist” of features that absolutely must be in the next release.

But releases planned in this way tend to feel disjointed and often fail to make an impact on your users since there's nothing tangible for them to bite on to.

Top-Down Release Planning

Top Down Release PlanningThere's a better way…and we call it Top Down Release Planning.  This type of release planning occurs when we first define an objective or goal for each release and then select only those backlog items that fit that objective.

This type of release planning can be a bit more involved since we must decide if each item selected fits the objective of the release, but it can lead to much more cohesive releases.  These types of releases often make a bigger impact on users which can resonate with them for a long time to come.

Why Bother?

You may be wondering why if Top-Down Release Planning is even a little more difficult then why we put forth the extra effort?  Well, aside from the advantages I mentioned already, highly cohesive releases tend to be much easier to build a memorable marketing message around.

In addition, focusing the release on a key objective also allows us to make greater strides in trying to solve a sticky problem that our users are currently facing.  If we can solve a particular pain point—and build a great message around that solution—then we're much more likely to deliver a release that will resonate with our users.

Want to Know More?

I cover Top-Down Release Planning in more depth in my course new course Agile Release Planning, available on Front Row Agile.  If you've ever struggled with building large-scale projects using agile techniques, or have just wondered how planning works in an agile framework then this course is a great fit.

In addition to Top-Down Release Planning I also cover

  • How traditional planning and agile planning differ, and how to start adopting a more agile mindset.
  • How to develop a vision for your projects, including creating a vision board and learning proven techniques to cultivate focused concepts.
  • Strategies for building a roadmap to your goal and important things to consider in the first release and all future releases.
  • Ways to plan the release, including how to develop a release grid and prioritize features well.
  • How to build the product backlog by looking through the lens of DEEP and constructing effective sprint plans now and far into the future of your agile development.
  • Methods to keep plans on track when things just don’t go as you expect.

This course is regularly $50 but for a limited time readers of this blog can get all of this content for just $40 by using the discount code PLANBETTER at checkout.  That's an additional 20% off just for following this blog.

Just enter the code above to claim your discount and be on your way to planning great releases and I'll see you in the course!

Comments Off on Release Planning from the Top Down

Type on the field below and hit Enter/Return to search