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.