Once you have a product backlog – it means you know what you are going to build and with which priorities – you can start your iterations and gradually build your product, functionality after functionality, always listening to the customers’ feedback and adapting to it.
You have already prepared a (draft) release plan so you know which functionalities will be built in every iteration, which known defects will be fixed but remember that this is just the initial plan (changes and new opportunities will arrive and will make you change the plan) and moreover the plan is a high level one, it does not go into details.
This is an analogue to Lean Manufacturing where you only build an Iteration Backlog when a Product Backlog is presented to you and requested to be turned into an increment; so this is Just In Time order processing.
Before actually starting with the iteration it is strongly recommended to have a planning session; this will also help as a kick-off for the team: what is expected from them in this iteration and what they can commit.
The purpose of the planning meeting is to give the team enough information to be able to work in undisturbed peace for a few weeks, and to give the product owner enough confidence to let them do so.
Give a title and a goal (overlooked but important!) and focus on the items selected for this iteration (which should be the very next items in the current backlog).
These are the important points to be followed in the session – for each backlog item – proceeding in priority order:
- Review: ensures that the team understand the item; in case re-discuss, re-prioritise the items.
- Organise: go for each item into the development, testing and deployment details; creates a sufficiently detailed plan to be sure the team can accomplish the item; this includes breaking down the item into tasks, estimating them (see note later) and finding the volunteers to do them (yes, the tasks are not assigned, team members sign up for them).
- Commit: at the end of this planning game you will have selected a number of items that the team forecasts they can accomplish; this resulting list of things to do is the current “Iteration Backlog”. It is a subset – but much more detailed – of the entire product backlog.
Together with the list you will also have a list of team members allocated and who gave their commitment.
The main outcome is a description of what the team will accomplish in the iteration in terms of tasks and stories, with the related goal (why do we do all this?) and its associated potentially shippable product increment.
Note the word shippable: everything needed to deliver this piece of product to customers must be realised: testing, documentation, installation, third-party purchases and everything else is needed: it’s not only developing the selected functionalities. It’s deploying them. This also means you have to take on board all the people with the needed skills, including some temporary team member if useful (it’s a cross-functional team).
To avoid the usual problem of concentrating on the what part and neglecting the why, keep in mind when defining the tasks that they contribute to the overall functionality and that they must satisfy at the end the acceptance criteria set by the product owner up.
My suggestion is to allocate some time to fix issues related to previously deployed functionalities (they will be found) and to refactor; how much it depends on the team and project: you can start with a 5-10% based on your own experience or instinct and adjust it iteration after iteration.
And is absolutely important that the product backlog is in a perfect shape before starting the planning game. Don’t underestimate this, otherwise the planning session will take much longer than needed.
Any team member can add or propose changes to the tasks. The tasks actually can / will vary during the iteration but this is ok, the Product Owner does not need to go into these details.
A final consideration: remember that the backlog (including the iteration one) is just a list of topics to be discussed, it’s not written in stones. The process itself can be modified, for example after a retrospective you may decide to adapt a couple of things to your specific context, team, project, culture.
Note: estimating is a chapter by itself and there is no perfect solution yet. A lot depends on the team members and the kind of project (is it a routine project with few unknowns or a green field project?).
You can find some possibilities in the internet (for example the poker planning method). I will add more details in a next post.