Welcome to part two of this series on
questions I’d ask during hour one of meeting with the team to get up to speed
on what they’re working on and how I could help or see where I know I could
help.
1.
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. Clearly actionable
stories to start the sprint should always be ready with others that can be moved
up to be worked when the first ones are finished.
2.
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. The PO should update the
stakeholder accordingly so they’re aware of the changes/delays in the project.
3.
What was your velocity of
the last three sprints?
The team should know its velocity, how could it otherwise
possibly improve? If you can’t measure
it, you can’t improve it.
4.
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 affect 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 that needs be
resolved asap or at the very least the next backlog grooming session.
5.
Are you changing user
stories once they become an item of a sprint backlog?
If so, under what circumstances are you changing the user
stories? 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. If they’re being made larger perhaps breaking
it out into two stories would be better.
6.
What are the obstacles
the team is facing today?
If they’re systematic what
ideas/tools/additional personnel brought on could be done to remove them?
7.
What are the dependencies
on other teams?
And if there are dependencies, are you waiting for other
teams to complete their tasks?
8.
Define and discuss at
least two or 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 SM or PO
understand team motivations and dynamics.
9.
What are key success
factors (KPI’s) 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.
10.
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.
11.
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. If there are differences that need mending
then a group setting may not be the best place to resolve said
differences.
12.
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. Often there are senior or tenured people on a
team mixed with newcomers that would love some mentorship and coaching. Making this a regular goal helps elevate team
cohesion, morale, and job satisfaction.
13.
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. Adding an impediment column to your workflow
might also help the team feel and see that though work has occurred that just
because it is stalled isn’t their fault.
Sometimes defects just need time outside of the team to be resolved and
having that column could help in your workflow and planning.
14.
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. While monetary rewards can be nice, if you
worked any amount of time you know other types of recognition often are more
valuable intrinsically to a team and its members.
15.
Who are the domain experts outside of our
team?
This is useful to establish who to
talk to when a story comes to an impasse, but perhaps an official designee for
resolving said impasse hasn’t been identified who could resolve the issue.
No comments:
Post a Comment