This guide is a list of suggestions you can implement as a Scrum Master when you are joining a newly formed scrum team. However, many of the suggestions described here may be useful in case you become Scrum Master for an existing scrum team.
Every time a new team is formed, it takes time to grow from a group of people to a well-functioning team. In their journey to become a high-performing team, they need a shared understanding of the principles and values of each individual and the team. The most important principles and values can be summarized in a team manifesto, a social contract among the team members. A team manifesto is always built by the team itself. It contains a set of norms, values and behaviors that forms a solid ground for collaboration within the team.
Building the Team Manifesto
With every team I coach, one of the first things we do is building a team manifesto. Recently, I did this by using the Retrospective format ‘That guy, this guy’. The results were great! Therefore, I would like to share this workshop format with you.
Plan a timebox of 60 minutes with the entire team
Bring flip charts, sticky notes and markers with you
Create two flip charts with: ‘Don’t be that guy…’ and ‘This guy rocks!’
Explain to the team what the goal of this session and a team manifesto is
Ask the team members to write down characteristics associated with ‘that guy’ (the person that you don’t want in your team) and ‘this guy’ (the person that is a perfect team member) on sticky notes, individually and in silence
Let the team members explain what they wrote down and collect the sticky notes on the flip charts
Consider to cluster the characteristics, if there is a lot of overlap
Ask the team members to prioritize the characteristics, by dot voting on the ones they value the most for the team (every team member gets five dots to divide among the items)
Select the five to seven most important characteristics
Divide the team in three groups and give each group a set of characteristics
Ask the groups to describe what each characteristic means for the team
Let each group explain what they wrote down and adjust this with the feedback from the other groups
Summarize all parts of the team manifesto on one flip chart and invite each team member to commit to it, for example by writing down their signatures
Make sure the team manifesto is visible at all times
A team manifesto ensures that the team coherence improves. It is a common understanding about the desired behavior within the team, and what it means for them to be a team. Since the team has ownership over the team manifesto, team members will behave according to it and encourage others to do the same.
There is enough LS which you can use to make your meeting productive. However, if you have the feeling that they are overused or you are bored with them, think about the five elements and create your structure.
How Space Is Arranged and Materials Needed
How Participation Is Distributed
How Groups Are Configured
The sequence of Steps and Time Allocation
An example of a retrospective with a new team: Situation: we have a team of 10 colleagues. A developer and I had just started on the team.
STEP 1: Ask the group to create two teams and give them the following assignment per team:
Team 1: take 10 minutes to think of all the reasons why this team is the worst team ever. after the 10 minutes, try to convince me that I have made a bad choice to join the team.
Team 2: take 10 minutes to think of all the reasons why this team is the most impressive team ever. After 10 minutes, try to convince me that I have made an excellent choice to join this team.
STEP 2: After both presentations, give the next assignment:
Team 1: take 15 minutes to discuss within your team what actions can be made to keep the most positive things that team 2 had mentioned.
Team 2: Take 15 minutes to think of actions we can take to dismiss some of the reasons that team 1 had mentioned.
STEP 3: After both presentations, ask each one in the group to think about the actions mentioned in Step 3 and take five minutes individually to find out how they can contribute to making those actions a success. You can also participate in this. We then share our contributions. Asked them to memorize their contributions, and get back to them in a few sprints.
How large is your product backlog? I do not believe in product backlogs that are larger than what the team can handle in three, maybe four sprints. If the product backlog exceeds this threshold, the product owner might be in need of some support.
What is the typical age of a user story in the product backlog? Again, I do not believe in the value of a user story that is 5 months old. And a “but I have been working on it ever since” is an excuse in my eyes.
What is your average lead time from an idea being added to the product backlog to its delivery? No one could answer that question in the before-mentioned session. But it is actually one of only three metrics that can provide some insight on whether “agile” has been successfully adopted by your organization.
Does your product backlog contain user stories none of the current team members is familiar with? Maybe those should be re-estimated with the current team members to make sure the estimation is still accurate?
How often are you grooming the product backlog? That should be done at least once a week depending on the state of the project.
On how many user stories are you working in parallel during backlog grooming? Ideally, a team should not be working on more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources on user stories that may never make into a sprint backlog becomes too high.
How long does the grooming of a typical user story take? The grooming should not be taking more than one to two sprints.
How are you creating user stories? (Is it a joint team effort with the PO or is the product owner writing the user stories and the team estimates them?) There is a tendency to observe that product owners become more a kind “technical writer” of user stories which then get estimated by the team. I suggest, however, to turn user story creation into a join effort of the whole team.
Where are you discussing user stories? Only during grooming sessions or also on Slack or via comments on tickets, for example? Every team has it own habits, and maybe commenting in Confluence, Jira, Github or utilizing Slack is an effective means of communication in your organization. As long as this happens before a user story is selected for a sprint backlog, this should be fine. Discussing its essentials afterward is a problem, though.
Do you apply a “definition of ready” standard to your user stories? That should indeed be a standard. A volatile velocity can at least partly be attributed to the lack thereof.
If so, of what criteria is your “definition of ready” composed of? Typical criteria for a “definition of ready” are: The description is available, acceptance criteria are defined, the story can be delivered within a sprint, all UI deliverables are available, all (probable) dependencies are identified, performance criteria are defined, tracking criteria are defined and the story is estimated by the team.
Who is writing acceptance criteria and in what format? It should be the product owner in collaboration with the team to create a shared understanding of what needs to be built.
How are you estimating the likely effort of a user story? An estimation poker would be useful.
Are you estimating in man-hours or story points? Estimating man-hours is betting than not estimating at all. However, I prefer user story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications becomes easier this way as they are featured with a built-in buffer.
How are you practicing the estimation process, if the team shares different opinions? Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.
What is a typical distribution of story sizes in your sprint backlogs? This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.
Are you re-estimating user stories at the end of a sprint? If so, under which circumstances are you doing so? That should always be done if a user stories turns out to be way off its original estimation.
What was your velocity of the last three sprints? The team should know its velocity, how could it otherwise possibly improve?
How many user stories are typically not finished within a sprint and for what reasons? If the team is bullish and picked more user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively effect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern. See also: Scrum: The Obsession With Commitment Matching Velocity.
Are you changing user stories once they become an item of a sprint backlog? And if so, under what circumstances? Well, making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers value. Making it larger after the sprint planning is, however, not acceptable.
What are the obstacles the team is facing today?
What are the dependencies on other teams? And if there are dependencies, are you waiting for other teams to complete their tasks?
Define and discuss at least three key team goals for the project. Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the Team initially. It can help the Scrum Master understand Team motivations and dynamics.
What are key success factors to achieve our team goals? Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues which the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.
What do team members hope to achieve with this project? I like to get a sense of people’s personal goals for the project in addition to the Team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance Agile Team, or have other goals.
What type of work environment do we want to create on this project? This question can stimulate good discussion about how Team Members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.
What can we do as a team to make sure that we support each other to achieve our team goals? This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, to take on roles outside their specialty, and trust their team when they need to ask for help.
What should we do when we are not achieving our goals or not supporting each other? Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.
How should we celebrate success for achieving our goals? It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards.