Who manages the overall product picture? - Certified Scrum Meetup

Last week Equinox IT hosted another Certified Scrum Meetup event in our Wellington offices. The event was facilitated by Principal Consultant Kirstin Donaldson and was run using a Lean Coffee format.

This time we used a Trello board to capture some questions and challenges before the event, as well as people raising new questions and challenges on post-it notes. The group then discussed the highest 'dot voted' questions and challenges.

The discussion for each of the highest 'dot voted' questions and challenges is summarised in the notes below.

For large-scale work over multiple products, who manages the overall picture?

Discussion included:

• Scrum of Scrums and Large Scale Scrum (LeSS)
• Having a Head / Chief of Product
• Starting a with Epics, and using a visual Epic board.

Can the demands of a Product Owner role be done effectively by a single person?

The person who raised this question was exploring having multiple Product Owners per team, one who could bring a business stakeholder perspective, one a technical specialist perspective and one a project manager perspective. Group discussion included:

• If the approach works for the team then keep going, if not inspect and adapt to something that does work
• The Product Owner role is the business stakeholder perspective, and the technical perspective is represented in Scrum by the Scrum Team and the project manager perspective is represented in Scrum by the ScrumMaster role.

What to do when documentation tasks keep rolling over from one sprint to the next?

Discussion included:

• Chunking working during sprint planning so that the work can fit within a sprint - for documentation, a large amount of documentation needs to be broken into smaller chunks and delivered incrementally
• Include documentation within the 'definition of done' for product user stories, so that documentation is delivered together with product features and the feature is not completed until it is also documented
• If need to catch-up on a substantial amount of documentation, potentially run a sprint that is dedicated to documentation to get this completed
• Work generally shouldn't roll over from one sprint to another, and if it does, then potentially there is too much work being committed to and too much work in progress per sprint.

How to get buy-in to do sprint retrospectives?

The person who raised this question said that the team is very busy delivering and it is a struggle to get these people together for a sprint retrospective. Group discussion included:

• Make it more attractive to meet, perhaps have just a 15 minute retrospective 
• Book retrospectives early, as part of the regular and expected team process
• Include retrospectives as a team commitment in a working agreement
• Put retrospectives on the backlog as a work item that needs to be delivered
• This issue may also be a symptom of conditions that mean the team is not able to work in Agile ways - e.g. the team is over committed, has too much work in progress, or is not dedicated to one project
• Use a physical kanban board so that work and 'too much work' is visible.

Ideas for sizing of user stories

Discussion included:

• Use t-shirt sizing XS, S, M, L, XL, XXL so that is is more abstract - then apply numbers after, e.g. XS = 1, S = 2, M = 3, L = 5, XL = 8, XXL = 13
• Dog breed sizes (e.g. Rottweiler vs Chihuahua) or fish sizes (e.g. Hammerhead vs Goldfish); can pick a subject suited to the team and this also helps create a better team culture.

How much planning is just enough? How do you know who decides?

Discussion included:

• Start with Epics, and use t-shirt sizing at the next level up, applicable to Epics. Apply Epic points on a larger time scale.
• If team is new to Agile look back at what has been achieved in the past to get a gauge for velocity - then learn and adapt from there
• Use consistent Epic / User Story templates to allow comparison for sizing - potentially co-create the template with the product owners.

How do you create user stories that are valuable and adequate?

The person who raised this question said that the team is really busy and doesn't have the patience to work on user stories. Group discussion included:

• Focus on user stories being a promise for a later conversation, so that story writing is not a prohibitively large task
• Use a good user story template
• Stick to good user story practice "As a user I want..."
• Use tight acceptance criteria
• Undertake really good backlog refining (and thus only need to put effort into priority user stories)
• Timebox each user story, say 10 minutes per story
• Use the 'three amigos' for user stories, representing product ownership, user experience and technical delivery, so that other team members are free to continue with other work.

We plan to host another Certified Scrum Meetup in March.