How to improve your team with one picture and 16 questions. Your task board is a treasure trove of information about how your team works. Mine it for facts and insights in your next retrospective (or even sooner) to improve both the retro itself and its impact. I call this a fact-driven retrospective, and here’s how it works.

Preparation: Take a picture or screenshot of your task board in mid-sprint. (Make sure it’s readable 😉 ).

Step 1: Answer the questions below. Most of them can be answered with a yes or a no, though sometimes you might say that the answer is not clear. You can do this step as preparation or as the first step in the retro itself.

Step 2: Dig deeper. Each “no,” “questionable,” or “not clear” represents improvement potential. Explore your answers to identify improvement potential.

Step 3: Remember the purpose of the retrospective is to improve quality and effectiveness, so pick one or two items to work on in the next sprint.

Combine these basic steps with facilitation techniques like pair and share, brain-writing, and dot-voting to come up with your retrospective format.

Let’s look at the questions, and then look at an example.

Good Scrum

1. Is there an item from the last retrospective on the Task Board?
2. Did the Developers make the forecast?
3. Do the Developers believe they are likely to achieve the Sprint Goal by the end of the sprint?
4. Are the Developers working according to priorities?
5. Are the Developers working as a team (pairing, swarming)?
6. What is currently slowing the team down?
7. Are there signs of external interference or control over how the team works?

Sizing

1. Are the forecasted backlog items ready (small, transparent, well understood)?
2. Are the backlog items small enough that the team can forecast 10 or more in the sprint?
3. Are the tasks small enough that each can be completed in one day or less?

Purpose and Priority

1. Does the team have a Sprint Goal?
2. Is the Sprint Goal aligned with the Product Owner’s true intent?
3. Are the forecasted backlog items aligned with the Sprint Goal?
4. Is the sequencing of the forecast aligned with the Sprint Goal?
5. If we only implement one backlog item this sprint, which one should it be?
6. If we fail to implement just one backlog item this sprint, which one should it be?

Analysis of a Sample Task-board

Good Scrum

Is there an item from the last retrospective on the Task Board?

No. There should be, otherwise the team is may not implementing improvements from the retro. IMHO it should be your top priority item, so it really gets done, and every sprint the team gets better.

Did the Developers make the forecast?

Questionable. The presence of card about pay-by-cash is suspicious.

Do the Developers believe they are likely to achieve the Sprint Goal by the end of the sprint?

Questionable. But we would have to ask to be sure.

Are the Developers working according to priorities?

No. No one is working on the top priority story. Only one person is working on the second priority story. Three are working on the third priority story.

Are the Developers working as a team (pairing, swarming)?

Maybe a little. It looks like there are 7 developers on the team. Two stories have more than one developer working on them, though in only one case are they currently pairing on the same task. On the other hand, that’s apparently a review task, so I am not sure if that counts.

What is currently slowing the team down?

There is a blocker on the first item that a stakeholder is not responding. The deeper impediment is the dependency. Why is done dependent on an external stakeholder. No one appears to be working on the issue.

Two items are getting the attention of three developers, even though these items do not relate to the Sprint Goal. This could be slowing the team down.

The tasks on pay-by-visa/mc are big enough that it is not obvious whether they are moving well or not.

Are there signs of external interference or control over how the team works?

Yes. The blocked story represents external control. The PO saying that cash payments should also be implemented in this sprint looks like excessive pressure on the team.

Sizing

Are the forecasted backlog items ready (small, transparent, well understood)?

No. There are 47 points on the board. The pay-by-visa/mc item is 21 points, or 45% of the team’s capacity. My rule of thumb is each forecasted backlog item should be about 10% of the team’s capacity, and no more than 15%.

Are the backlog items small enough that the team can forecast 10 or more in the sprint?

The first two items are marginal. Each one is 8 points, or 17% of the team’s capacity. If they were all that size, that translates to about 6 items per sprint. One like that be okay, but overall, that’s too big. Again, the pay-by-visa/mc is way too big (aka TFB).

Are the tasks small enough that each can be completed in one day or less?

The tasks in for pay-by-visa/mc are the same as for the other items. But because the story is 4 times bigger, each task is way too big. You will not see much movement on the task board on this story. You want to see tasks get completed every day.

Purpose and Priority

Does the team have a Sprint Goal?

Yes.

Is the Sprint Goal aligned with the Product Owner’s true intent?

Moderately. Stories 2, 3, and 4 are about paying by credit card.

Are the forecasted backlog items aligned with the Sprint Goal?

Questionable. The top priority story is about checks, not debit cards.

Is the sequencing of the forecast aligned with the Sprint Goal?

No. The first story is not aligned with the sprint goal.

If we only implement one backlog item this sprint, which one should it be?

Probably one of the pay-by-card stories, i.e. 2 (Amex) or 3 (Visa/MC). My choice would be driven by which is more important for business. I would not be surprised to discover that it is really pay by cash.

If we fail to implement just one backlog item this sprint, which one should it be?

Probably story 1 or 5, but the question about product owner intent remains.

Improvements

Now you’ve read my diagnosis, what would you add? What did I miss? What did I get wrong? Different people will spot different things. Use the discussion in the retrospective to build a shared understanding of what the issues could be.

Given the diagnosis, what could you do about it? Again, let your team come up with ideas, then prioritize them for best impact on quality or effectiveness. Some might be doable with a snap of your fingers; some might need concerted effort from the team. At least one such item goes into the Forecast for the next Sprint.

PS.