Category Archives: scrum

Predictability Doesn’t Involve Predictions

When I say the word “predictability,” I think people assume that I expect them to be able to predict what they’re going to be doing 3-6 months from now.  They think I’m asking them to make predictions based on estimates.


In reality, I’m asking them to behave predictably so we can have some empirical evidence to combine with estimates as a way of making forecasts.  There are a couple things that are required for teams to behave predictably.

  1. There needs to be a backlog of work that is broken down into small chunks.
  2. The team needs to complete the small chunks of work in a disciplined manner, limiting the work in process and producing working, tested code on a regular, frequent cadence.

Breaking work down into small chunks is a skill that is developed with practice.  It’s not easy to begin with and many people get frustrated to the point that they say it can’t be done.  My experience has shown that there is no work that can’t be decomposed without some effort.  Sometimes that effort even involves doing a little piece of the work, especially if it’s a type of work we haven’t done before, but once the means to the end is roughly understood, the work can be decomposed.

If the work is relatively large (the definition of “relatively” varies by domain and level of experience), we don’t need to decompose all the work to the finest level.  We need to break all the work down into intermediate chunks and then we need to continuously decompose the intermediate chunks so we maintain a rolling backlog of finely-decomposed work.

Even the method of estimating I prefer doesn’t call for predictions.  I prefer relative sizing over time-based estimates.  The only “prediction” I’m asking for is how much larger or smaller one piece of work is over another piece of work.  I don’t want you to predict how long it’s going to take to do each piece of work.

I’m really trying to give teams a large degree of control over how they will accomplish an objective, but I’m asking them to be transparent about the backlog of work items required.  I’m also asking them to give me an idea of the size of the items so I can make continuous forecast adjustments of my own based on the pace at which they are progressing through the backlog.


Interesting Aside

It’s interesting to watch the evolution of work decomposition and estimating in a stable team.  When a team works together over a period of time, they unconsciously develop an idea of the preferred size of a work item.  This is the size that a work item needs to be before team members feel comfortable that they have a clear understanding of it.  As teams develop this norm, the size of all their work items in the near-term backlog converges on this size.

Scaling Agility – Collaborative Scheduling

I spent today at the first day of a two-day course at DevJam titled Scaling Agility.  The main focus of today was working within teams and we started to get into working across teams in the last hour.

One of the exercises I could see using made scheduling tactile.  The prerequisites are a set of prioritized and sized backlog items (e.g. stories).  You also need to know the capacity of a time box.

Each backlog item is listed on a card that corresponds to its size.  These cards are then placed into time boxes.  The cards can’t overlap and no more cards can be placed in the box than there is capacity.

Another key aspect of this exercise is that it needs to be done collaboratively with a group of people who can represent the feasibility, value, and usability of each backlog item.

You can see an example we worked on in class below.  There is one large item, one medium item, and two small items in the first time box (left side of the left piece of paper).

Collaborative scheduling example.
Collaborative scheduling example.