Building a Backlog
Once you or your Product Owner has defined what products you need to deliver and what the definition of done would be, you need to break down those products into their component parts. Identifying the components is one way of building a backlog as you essentially list all of the building blocks needed to deliver the end product.
Use a whiteboard
You want to start with a large space, a whiteboard or a wall and a big pile of post-it notes, begin by identifying the product, then ask the team to break it down into deliverable sized chinks.
A chunk will vary from team to team, something can be built in isolation and others cannot, some can be built in a few short hours and others may take a few days. Some teams will define rules such as ‘a task must have zero dependencies and be deliverable in 8 hours‘ which is very precise, a newer team, or a team that is new to Agile delivery will not have this level of maturity, don’t let this hamper you, keep asking the team ‘do you think you can deliver this in 1 day?‘ and ‘does this rely on or block anything else?‘.
You may find those initial meetings are a little clunky, you might need to coach extensively and you might find yourself questioning your own requirements. Take breaks and keep plugging away at it.
Every time the team identify a component, write it on a post-it and stick it on the wall. Once all of the components have been identified, ask the team to help you put the components in order, we need to ensure we hit the blockers first, then we might look at priorities for example; if you are planning to build a product that completely changes the way an order is taken on a website which includes a new way of linking to related items so as to maximise the value of a customers cart, it may be that the ‘related items’ module is not a blocker for anything, but actually, if we can deliver that first we could enhance the current or legacy website ordering system, increasing the value of the cart and having a positive impact on the companies financial performance much earlier than if the company waits for the entirely new ordering system. As such, we might want to bring this new module to the top of the pile so that the team can work on it earlier.
Pull not Push
Another thing to work on, for both the team and the Product Owner is the concept of Pull vs Push, this is difficult for new product owners to get the hang of, they often want to influence the order of the work, which they do, in one sense, but not down to the individual tasks.
The primary idea is that a Product Owner should identify which products or features are the most important to the success of the project and the team should always take work in an order that meets these priorities, however, it is for the team to manage their workload. If the team knows that today they can do this 6 hour high priority module and that 2 hour low priority module in a single day, the team member is free to make those sorts of decisions.
When does it stop being Pull?
Unfortunately there will be occasions where your teams want to take all the fun work but leave the dull stuff like updating documentation in the to do column. Now I know that documentation takes a second place in agile delivery but it is still important, especially to older organisations, or those that are heavily regulated.
The priority of the product and the tasks that make up the product must be respected by the delivery team. That essentially means that although you do give some freedoms to the team, you do still have some control over how they work by ensuring that the priority of the dull work, like documentation, is recorded at a suitable level.