This article describes a number of templates that are useful for Scrum teams. Each template is briefly described here. Access to each template requires a subscription to Premium Content. 

Mindset templates

Outcome-Based Thinking Mindset

The Outcome-based Thinking Mindset  template supports the shift in thinking required from merely working on a literal reading of a backlog item to understanding the intention (the outcome) of the backlog item.

Definition of Ready and Definition of Done Template

A Definition of Done mindset is one of not starting the implementation (or even the next step in a workflow) until you’ve determine how you will know you are done.  This includes not only immediate functional acceptance criteria but can also adhering to standards and regulations, and meeting non-functional criteria such as creating or updating documentation and obtaining approval from specific stakeholders.  We have found that starting work before making these criteria explicit is one of the leading causes of unpredictability and re-work.

A Definition of Ready mindset is one of not starting the implementation (or the next step in a workflow) until you’re ready to get it to Done. Over time, a team’s Definition of Ready will expand to incorporate additional readiness elements that the team has found to cause failure, rework, and other types of waste when not attended to.

The Team DoR-DoD Template is focused on what a typical software development team may need but it can be applied to other types of backlogs such as shared services and operations backlogs, program and portfolio backlogs.

Also, ensuring that what is being built can be delivered should be part of the Definition of Ready for an MBI.

MBI Mindset Exercise

A Minimum Business Increment (MBI) is the smallest chunk of work from which we can realize business value. An MBI Mindset is one where, to obtain a specific goal or outcome, we always attempt to discover and select the minimum scope needed to realize the desired goal/outcome.

---

Team Agility Scorecard

The Team Agility Scorecard is a matrix to help you score how well different aspects of Team Agility are being done in your organization. Use it as a road map to guide improvements for an Agile team, to choose what to work on next.

---

Team Approaches and Practices Templates

The components of a good Scrum/Kanban Board

Scrum and Kanban originators have different mindsets about the visibility of work. Scrum is described as an empirical process without there being a consistent flow. This is why it uses tasks on stories – because then each story can have a unique workflow.  Kanban is more directly based on Lean. In particular, systems-theory, the value of visibility of work to collaborate and the value of a standard workflow on which to make continuous improvement. Kanban’s perspective on team boards can easily be adopted by Scrum teams and is usually always beneficial to do so.

See Components of a good Scrum/Kanban Board

Choosing practices

Think of Scrum as the top shelf of a large toolbox. Everything you need to start with is there. You only need to go into the larger part when one of the topmost tools is having a problem getting the job done. When a team is faced with a challenge in following Scrum, they go to the toolbox to ask, “What objective does this practice meet?”, “What decision have I made?”, and “Is there a better way to do this?”

See How we agree to new practices

Retrospection: After Action Review

The After Action Review is a simple and powerful tool to help a team learn from their experiences in order to gain immediate, concrete improvements in performance. It is a more general and widely useful approach than the retrospection. An “action” is any major or routine activity or event that a team of people undertakes, especially those events that they or other similar teams will likely repeat in the future.

Also see How to facilitate a retrospection.

Classes of Service

The work done by most organizations falls into different types. For instance, a capability you are developing may have to be delivered by a certain key date: If the capability is not delivered by then, the amount of value it delivers drops precipitously or there may even be legal consequences. This is very different from work that “gets done when it gets done.”

Classes of Service are the main types of work done by the organization/team. Different Classes of Service are differentiated by their amount of time pressure or urgency, as well as separate needs such as making sure that at least some items of a given type are worked on.

See Classes of Service.

Guardrails at the Team Level

The Guardrails for Lean-Agile transformation are a set of agreements and questions to help the organization assure it is staying on course in its transformation and to be able to make decisions at a local level that are aligned to the rest of the value stream.

See Agreements to make with other teams and management.