7

After a Retro we usually have 2 or 3 Actions to address in the next Sprint. Some of these Actions are sometimes more of a reminder to Developers.

Who do we ensure they are addressed in Sprint?

We're using TFS as the ALM tool. We do view a Kanban Board at each day's Standup.

4
  • Experiment. What has your team tried so far? Why these solutions failed, from your perspective? – Tiago Cardoso Nov 30 '20 at 9:45
  • We've create PBI with Tasks and tagged them as Retro actions. These came up in the Standup from time to time but most did not get executed. – learnerplates Nov 30 '20 at 10:33
  • 2
    @learnerplates Do you know why they don't get executed? In my experiences, making sure the team checks in on their progress during the Daily Scrum is a big first step. A lack of visibility into the retro actions is usually one of the biggest gates. Once there's visibility, revisit to see why the team isn't getting them done. – Thomas Owens Nov 30 '20 at 11:15
  • If you're using PBI's then you're using the CMMI template. The CMMI template comes with Sprint Retrospective Item as a WIT. Use those, and put them in a place the team can access them (a dashboard query perhaps). Use the items to inform your definitions of, and/or your sprint goal. – spikey_richie Dec 1 '20 at 8:38
7

Retrospective actions are a vital part of the Sprint work, so they should be agreed with PO and tracked as such.

You mentioned you use a Kanban board. Why not tracking each action as an item in the board? You may want to have a mean to separate these items from the other Stories, but it all boils down to what works better for you.

In our team, we use a specific swimlane for team goals. On these goals, we have both the actions from the retrospective alongside the goals the team agreed to deliver at the end of the sprint. That's one way amongst several other similar organizations.

Bottomline: The Actions should be visible to the team on the team board. The best way for a team to make it real depends entirely on the team itself, exploring and experimenting different approaches.

2
  • Yes, a specific Retro Actions column is what I am trying now. Some of our actions are actually more reminders to the Team of what to try next e.g. keep WIP limit to 3. – learnerplates Nov 30 '20 at 10:35
  • 3
    @learnerplates That specific example seems like an anti-pattern. A WIP limit should be a constraint clearly set on your kanban columns, lanes, or board, not a task or reminder tracked as work. – Todd A. Jacobs Nov 30 '20 at 23:50
4

TL;DR

A Sprint Retrospective is part of the inspect-and-adapt process. The 2020 Scrum Guide says that "[t]he most impactful improvements are addressed as soon as possible," but doesn't prescribe how the team must implement any given adaptation.

The whole Scrum Team is collectively responsible for working together to decide how to best implement needed changes. If the team isn't doing that, it's not being self-managing. If the Scrum Master isn't facilitating the team's self-management of its own continuous improvement process, then the role's accountability for "[c]oaching the team members in self-management" isn't being effectively performed.

Since the whole Scrum Team is collectively responsible for managing its own continuous process improvement, when in doubt ask the team how they plan to implement and evaluate the adaptation. Without a team-driven plan to both institute and validate proposed changes, there's likely insufficient buy-in or commitment to bother tracking them.

Retrospectives are for Identifying and Defining Adaptations

As a practical matter, items from a Sprint Retrospective tend to fall into a few broad categories. Process changes should be implemented as soon as possible through the appropriate team process or artifact. Examples include:

- Updates to the Definition of Done.
- Changes to the way Sprint Backlog Items are handled.
- Modifications of the team's information radiators (e.g. Kanban board or story cards).
- Other adaptations to the Scrum Team's processes, artifacts, and events.

Retrospective items aren't usually "work" in the sense that they're first-class items to be tracked on the Product Backlog, but there are always exceptions. If you have such an item, such as "Embiggen the Team Frobnosticator," then you should certainly have worked with the Product Owner to add that to the Product Backlog already.

The rest of the items are things the Scrum Team should collaboratively be handled directly. For example, trivial updates to the Definition of Done should just get handled, so that the team can immediately take those changes on board. Non-trivial changes related to the Product Goal that include measurable work should be on the Product Backlog. However, when the work is more of a chore or task, it belongs on the Sprint Backlog as a work item instead.

Measurable action items belong in one of Scrum's defined artifacts. Less-measurable items (e.g. adaptations to the way the Daily Scrum is implemented or facilitated) should either be decomposed into measurable actions, or part of the empirical control process. In the latter case, empirical control may be as simple as asking the team at defined intervals or at the next retrospective whether they think X has improved.

In most cases, the Scrum Team should be coming out of each Sprint Retrospective with something actionable and measurable. As the Scrum Master, being the process referee is part of your job, and that includes calling out hand-wavy "action items" that aren't actually actionable or measurable. Get the Scrum Team to focus on using the Sprint Retrospective to continuously improve process in a measurable way, rather than just kvetching about things that the team can't or won't take responsibility for addressing in a self-managing way.

3

Two cases come to my mind

  • Is everyone ok with you sharing the information?
  • Does it make sense to share all information?

Once you clarify that everyone is ok with sharing that information and you decide that it's a valuable information to share, great.

My suggestion in how to share them would be based in a bullet from this answer

Do a retrospectives on how you have been improving as a team

So in the next retrospective you could bring up that concern of yours. Something like

During the last retrospective we identified we should do X, Y and Z during the next Sprint. Yet, we didn't consider them. Do you think these are still actions that need to be done? If yes, what's do you think it's blocking us from doing so? And how could we ensure it gets done?

Remember that as a Scrum Master...

... has the attitude of helping the team to solve its own problems rather than solving the problems for the team

1
  • Yes, reviewing the previous actions will help and ask the question why did it complete. Some of the Team actually asked for SMART actions, I've posted below. – learnerplates Nov 30 '20 at 12:42
0

We rarely have more than one item raised per sprint that we can do anything about so we raise them as stories and track them in the following sprint (or however long we're working on them).

We're an internal IT team so there's nothing from a retro that we wouldn't put on a board that our PO can see. Transparency applies to these items as to anything else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.