Questions I ask to get up to speed on a new scrum team as a product owner or a scrum master Part 2

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.

Questions I ask to get up to speed on a new scrum team as a product owner or a scrum master Part 1

You’re excited about your new badge, the cheerful HR team, a new company and culture, new products and services that you’re working on, but then you have your first meeting with the team to discuss everything that they’ve been up to their necks in for the last who knows how long and you’ve got to show you can help and fast, but how do you do that?  This will be a multi part series on how I’d navigate my first hour of work in a new role as a Product Owner or Scrum Master.

There will be meetings and greetings to get to know the team and the product, but the following questions are what I would ask during my first sit down with the new team to get to know what it is they’re working on and need help with immediately, with the implementation of scrum, and what long term things we can start to work on.  Certainly the trainer/manager that I’m reporting to might have all this good and covered, but I bring this to you to show what I’d do if there wasn’t structure on a team as it relates to Scrum and how I’d get started if so.

1. How large is your product backlog? This helps to gauge how much work is planned in general, but also how much creativity has gone into the product and how much help the product owner might need.
2. What is the typical age of a user story in the product backlog?  If stories are quite old, i.e. they’ve been in there for 5 or 6 months either due to neglect or its an ongoing story than either it doesn’t have enough detail to close it out in a sprint or it is potentially not relevant anymore to the product, but it has become someone’s baby they aren’t willing to let go of.
3. What is your average lead time from an idea being added to the product backlog to its delivery?  This question helps detail how well agile is actually being implemented.  If it is taking several sprints worth of time to deliver an idea then agile is being ignored in terms of definition of done and estimating correctly.
4. Does your product backlog contain user stories none of the current team members are familiar with?  Maybe those should be re-estimated with the current team members to make sure the estimation is still accurate?  It could be also that the stories are no longer relevant if nobody knows or cares about it.  Every story in a product backlog in agile is technically owned by the entire team and so nobody being familiar with an item is actually a problem of how well everyone is bought into the product vision.
5. How often are you grooming the product backlog?  That should be done at least once a week depending on the state of the project.  For one month sprints 1-2 times a month might be more realistic and effective because not a lot will have changed and need to be renegotiated.
6. 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.
7. How long does the grooming of a typical user story take?  The grooming should not be taking more than one to two sprints and grooming sessions themselves shouldn’t really last more than an hour.
8. 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?) While it happens and isn’t against the law that a PO writes a story and they may have previous experience as a technical writer it is best that the whole team write the story together to be sure all details are flushed out.
9. Where are you discussing user stories? Are you discussing them only during grooming sessions or the daily standup or also on Slack or via comments on tickets?  Every team has its own habits, and maybe commenting in Workfront, 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.
10. Do you apply a “definition of ready/done” standard to your user stories?  That should indeed be a standard. A volatile velocity can at least partly be attributed to the lack thereof.  While TMI is a thing in social media, rarely is it a problem when crafting a definition of done in your user stories.  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
• The story is estimated by the team.
11. Who is writing acceptance criteria and in what format?  It should be the product owner in collaboration with the dev team to create a shared understanding of what needs to be built.
12. How are you estimating the likely effort of a user story?  An estimation poker would be useful.  You can gauge based on past projects and their component parts.  Bringing in domain experts outside of the team will also aid in those pieces that aren’t to be done within the dev team.
13. Are you estimating in man-hours or story points?  Estimating man-hours is better 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 and less micro management on the part of the stakeholder who may be using a stop watch (and a whip) for when estimates go over.
14. 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 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.

Scrum Backlog Grooming and why

In purist scrum planning you can plan a sprint, which is a time boxed event of development/work of anywhere from a week to a month, during what is called a Sprint Planning Meeting.  These sprint planning meetings can last up to 8 hours for a one month time box sprint.  That is a long time to plan all the work that is going to be done in the next month.  Not to mention that perhaps things will change during that time that will make some or much of the planning irrelevant as time goes on.  This is possible in situations where consistent work hasn’t already been done with definitions of done completed and estimates by the dev team provided.  Where there has already occurred plenty of work that can be looked back on and estimated accurately going forward you don’t necessarily run the risk of planning that is useless since you already have a good idea of what it is going to take to do the work.

All that said how can you potentially cut down on the amount of time a sprint planning meeting will take?  Answer: Backlog grooming sessions.  Ideally these sessions happen regularly so that the sprint planning meetings are both shorter and more effective.  These sessions are meant to improve the product backlog.  In it you can:

• Write/update user stories
• Decompose a story into several stories that are too big to realistically be done in a time box sprint
• Devs often love as much detail as possible to accomplish a story and so adding more definition or rewriting poorly constructed stories is useful
• With the dev team estimate the backlog items that haven’t already received estimates
• Add acceptance criteria and flush out the definition of done
• Assess deeper (lower down on your product backlog) stories/backlog items and do long term planning with domain experts or just when those items can be done.

Yes it is important to stay focused on the current workload, but don’t get too hung up on not looking beyond the current sprint if needed.  Just because you’re on schedule for the next release doesn’t mean you can’t proactively look to the future and see what additional research, domain experts, or technical hurdles may need to be addressed now before getting to the future.

So good things to do during a grooming session:

Have a stated goal.  Everybody hates meetings that drone on and don’t actually accomplish anything.  Devs especially hate this since they’re up against what they’re already working on and being in a pointless meeting just takes them away from the work they need to get done now.

At the bare minimum hold your grooming session a few days before the sprint planning so people are familiar with the backlog and can hit it hard during the actual planning session.

If you have stakeholders present, limit them to just a handful.  Don’t have 10-20 people in the meeting because they often don’t know the rules of scrum, will make things chaotic, plus people check out when there are too many people in a meeting anyways and input by default is minimized by the sheer size of the group whereas smaller groups can have more people contribute.  Go figure.

Implementing regular backlog grooming meetings helps sprint planning meetings go better and more efficient, familiarizes the team with what is on the product backlog, which then leads the team to committing easier to sprint goals/commitments.