Product Management

In order to avoid lots of panic and chaos the day before sprint planning because there’s no work in a ‘ready‘ state, it’s essential to have regular backlog grooming sessions which would result in having at least six weeks’ worth of high priority ‘ready’ work in the product backlog.

To get PBI’s (Product Backlog Items) in a ready state, it can take a lot of effort especially when it comes to chasing down dependencies or getting answers around the business requirements, but this is where the whole product team (product manager, product designer and engineers) can work together to get the answers they need to solve the problems. Having frequent backlog grooming sessions, so there’s a good few weeks worth of ready PBI’s helps.

A new PBI is the start of a conversation and shouldn’t include solutions, so there should be ongoing questions around the requirements well in advance of the work going into development, until the development team feel they have enough information to size the PBI and then mark it as ready if there’s no dependencies.

It’s important to have a good quality product backlog (high priority items in a ready state) and frequently groom PBIs, to ensure the development teams are not only working on the highest priority items, but also that they’re working in an efficient way.

Some tips to getting a good quality product backlog:

1. Create the user stories and prioritise in the backlog sooner rather than later – as a minimum the story needs to include ‘as a’, ‘I want’, ‘so that’ language with some high level acceptance criteria which will help start the conversation with the developers, giving them weeks to ask questions up front before it appears towards the top of the backlog.
2. Making the value and problem / requirements clear with a stakeholder point of contact within the story for reference
3. Having a clear title (summary) to the story, so you don’t have to open it up to find out what it’s about
4. When there are questions from the developers to answer either by the product manager, stakeholders or technical, try to avoid leaving these unanswered for days – these should be responded to immediately as a priority
5. For the ‘Feature Backlog‘ to be presented to the team monthly or bi-monthly, so they know clearly what the value of the relevant PBI’s are with some context around them
6. Having flexible backlog grooming sessions – there’s no rule here, the teams can get together everyday if they like to groom the backlog until they’ve caught up
7. Reinforcing to the development teams that they don’t need to know exactly what code to write and where in order to size the PBI, but instead the sizing should be based on a suitable solution making some assumptions
8. Attaching customer flows / UX to the PBIs, with a link to ‘As Is’ and ‘To Be’ documentation

At least 10% of the teams time should be spent on grooming the product backlog and unless enough time is invested or they don’t get the support they need from the Scrum Master or Product Manager, then there’s risk of inefficiencies or the teams working on low priority PBI’s (Product Backlog Items) as the high priority items aren’t being groomed enough in time for sprint planning.