My shopping cart
Your cart is currently empty.Continue Shopping
Kicking off with Scrum
Essential techniques you need to survive and thrive with Scrum
Scrum is an empirical process based on a series of mini-projects called “sprints” which last 1 to 4 weeks.
Teams consist of a scrum master, who facilitates the workings of the process, product owner, who decides on requirements, priorities and goals, and developers or other experts that deliver complex work.
Kicking off a new team
Many of the processes used to succeed with Scrum are not specified by it. Teams work within a framework but choose a great many details to suit themselves and their environment.
We've created 20 question cards that cover the Team, Collaboration, key Policy decisions and outside Relationships. Use them to prompt useful open-minded conversations.
You may find some issues cannot be resolved until later sprints, or you might have to research unfamiliar topics. Use the cards until you are confident your processes can deal with common problems and emergencies. Agree the kinds of emergencies you are committed to working through with your key stakeholders.
Given a backlog of product features, a planning meeting first identifies a goal. The goal must be a subset of the product backlog which is forecasted to be achievable in the sprint. Forecasts should be based on statistics as soon as possible. You should set up processes to capture how long features take to deliver, and the complexity of each item.
Given a set of features, a rating of their complexity, and your statistics, the team can produce a likely completion date.
This game divides features using an intuitive estimate of complexity for each. More complex features are given a larger size rating. The sizes are only meaningful in relative terms, and with respect to statistics.
Players talk over a feature and might make a list of tasks needed to complete it. Together, they share their chosen size. The cards are S, M or L : Small, Medium or Large.
The players with the highest and lowest sizes compare their reasons for seeing the feature differently. Examples of previous features can be used for guidance.
The process is repeated until there is consensus on a rating, which is then recorded, and the next feature is considered.
Similar processes are available for forecasting features in larger numbers, or using story points for greater accuracy.
Scrum’s empirical character extends to the evaluation and adaptation of the team and its processes. Scrum defines many opportunities to inspect and adapt, the most comprehensive being the sprint retrospective at the end of each sprint.
The retrospective is a chance to share what went well, what went badly, what impediments exist and what support is available. There are many techniques for eliciting this information from the team.
Once gathered the inputs are usually prioritised for further discussion using dot voting. Once there is a shared understanding, team agrees a series of actions which are tracked as part of the team’s workload.
The traditional view is that motivating teams means offering financial incentives. For complex work, these rewards have been found to be counterproductive. Creativity and sound reasoning must be motivated from within. One way to promote this kind of intrinsic motivation is through praise and appreciation.
Exchanging tokens of appreciation helps people to know that their performance is valued. Teams are achieving successes with simple notes of appreciation on A6 Index cards. The cards have space for a brief note of thanks, giving some details about exactly what the recipient did and why it mattered.
Stickers can be used to add further depth and some decoration. They invoke common events such as late nights, performing to targets and solidarity. Our sticker set allows for 60 colourful combinations.
Cards are exchanged top down, bottom up and peer-to-peer and between teams in different departments. If collected in a box they can be read aloud at team ceremonies, such as retrospectives, or used for the basis of a reward system. Any financial incentives linked to the system must be small.
The board is a shared visualisation of your work, your process and it’s state. Build ups of tasks and even blank areas can act as a prompt to shift priorities. Is it right that there is no design work in progress? Is testing about to become a bottleneck?
Keeping a visible record of task-level status helps stop stories being hogged by one person, who becomes a knowledge silo. It also encourages “swarming” where team members cluster around one story to drive it through to completion.
The board is a natural space for team policies, such as the definition of done, and column entry and exit criteria. Should the team confine itself to a physical, rather than digital, board it will find itself with fewer distractions, greater responsiveness and more flexibility. There are also superior visual cues that provide early warnings of process related problems.
As long as you inspect and adapt your processes you won’t be wrong for long. Sticking to dogma may leave you in trouble.