There’s an Extreme Programming concept, tool, practice that many have forgotten. Sure, we remember user stories, refactoring, TDD, continuous integration, and pair-programming among the more popular XP practices. 

But there are some that were quite useful and meaningful that we’ve misplaced. One of them is release planning as described in the Planning Extreme Programming book by Kent Beck and Martin Fowler.  

Another is the notion of “Yesterday’s Weather”, which is a much simpler concept. I want to focus on it though as a powerful thinking tool for today’s agile teams.

Yesterday’s Weather

Here are two references:

It’s a simple concept really. It implies that a great way to plan for the future is for you to look at the immediate past for performance indicators. For example:

  • If you produced 25 story points of “mass” last sprint, odds are you’ll produce approximately the same this sprint;
  • If you’re team was interrupted for 30% of their time last sprint with maintenance and support issues, odds are you’ll get the same interruption level in the next sprint;
  • If you were struggling with external dependencies to other teams in the last sprint, odds are you’ll experience that in the next sprint; 
  • If you’re leadership team entirely changed their mind on the contents of your last sprint AFTER the sprint started, odds are they might change their minds again; 
  • If your team planned to deliver 10 stories but only delivered 5 “done” stories (carrying over 5 stories the next sprint, odds are they’ll do it again in the next sprint.

And so on… We can use Yesterday’s Weather to either plan differently or to illustrate an impediment that we (the team, the group, the organization) needs to resolve.

What’s surprising is…

How frequently we forget the past. It seems that teams are always optimistic when it comes to the next step, or day, or sprint. We always think that something miraculous will happen that will change the fundamental dynamics of our work. 

Yesterday’s Weather tries to remind us that, while it might be possible to have things fundamentally change, it’s often not likely.

Concept of Drag Cards

I forget when I first introduced this concept to an agile team, but it must have been over 10 years ago.  

I’m sure it was with a team who was struggling with executing their sprint and delivering to their sprint goals. And in several retrospectives, the team really struggled to “pin down” what was happening to their sprints.

I suggested to the team that during the next sprint they throw a “drag card” for each off-plan interruption. That is, if something happened that wasn’t in the sprint backlog (plan) they should place a card on their sprint board with the name of the person, the interruption and the number of hours that they were pulled into something else.

We agreed that the granularity of the timing would be in increments of 2-hours. And that they wouldn’t over analyze the cards during the sprint.

But at the end of the sprint they would review, add up, and sort through the factors that caused the team to miss their sprint commitment. I think in the first sprint it was external customer support and defect fire-fighting. At the end of the sprint, they discovered that 40% of the team’s time was spent in these areas. And not surprising, they missed the sprint burndown by about 30%.

The drag cards gave them data to (1) defend themselves in their sprint delivery and (2) provided a focus for where they needed to improve in order to gain more predictability.

From that point forward, I’ve always recommended collecting and analyzing drag cards for teams who are churning to a degree. And keeping within the theme of this article, the drag cards represent Yesterday’s Weather when planning the next sprint.

Wrapping Up

I truly wish more teams leveraged their historical data when planning. Even if that data is more anecdotal than concrete.

It requires some openness to history and applying a realistic (vs. optimistic / hopeful or pessimistic) style of planning. It also requires observation of your journey, so capturing incidents or journaling in some way can be quite helpful.

Hopefully the next time you find yourself struggling a bit within your agile team, take a look back at Yesterday to plan your way Forward to Tomorrow.

Stay agile my friends,

Bob.

Comment