EVERY PROJECT STARTS WITH A VISION
Every agile project starts with a product vision. The product vision is the project’s true north. The product vision paints a picture of the future that guides the team forward. It describes what customers need and why, and captures the reason why the product exists. At the heart of the product vision are the customer needs and product attributes that meet those needs. It answers questions like: What do we need to develop and launch a winning product? What does success look like?
Getting the product vision right is key to guide the team and align stakeholders and customers. The effort spent on creating the product vision is a worthwhile investment.
While the vision answers the question “What do we want to do and why?”, the product roadmap takes care of the “When do we plan to get it done?” The product roadmap shows the high-level targets and the planned steps to get there. The product roadmap is a powerful tool to organize the journey of product development.
The product owner creates both the product vision and the roadmap with help of the development team.
DEFINING REQUIREMENTS WITH USER STORIES
Before we step into release planning, let’s review some agile essential planning artefacts.
Let’s start with user stories. User stories are short, simple descriptions of a feature explained from the perspective of the user or customer of the product. They typically follow a simple structure:
As a < type of user >, I want < requirement > so that < business case >.
Examples of user stories are:
As a user, I want back up my entire hard drive so that my files are safe.
As a student, I want to purchase monthly parking passes over the university intranet.
User stories must be written in clear, direct language. In Agile, Themes are broad groupings of targets defined by the customer. The next level of detail is called epic. Each epic represents a large chunk of customer value and they can be used to organize stories into groups.
In following example, we can see how a large theme “Increase use of University Intranet” is broken down into epics, stories and tasks for better organization.
GETTING DOWN TO AGILE PLANNING
Just enough planning, just in time. Agile Planning revolves around these foundations. Agile accepts the fact that every relevant detail of a project isn’t known at the beginning. By using this practical approach to planning, agile adapts better to change. In Agile, we plan from big to small. We start with a high-level idea of what we want to achieve, then break down the details.
The Product Backlog is simply a list of all things that need to be done within the project. The Product Backlog evolves as the product progresses. The Product Owner owns the Product Backlog and defines, organizes and prioritizes its content.
PLANNING RELEASES WITH BACKLOGS
The Product Backlog is broken down into release backlogs. By organising the backlog into releases, we can estimate roughly which features will be delivered by the release deadline. Inputs to the release plan include the product vision, the product roadmap, and dialogue with the team.
To plan how much the team can deliver, a good estimate is needed. Since Themes and epics aren’t actionable in themselves, most Agile Estimating is done through User Stories. Stories should be also sized according to their complexity, uncertainty, development effort and external influences. There are different ways to size stories, but the main idea behind it all is to simply estimate the size of each Story in comparison to other Stories in the backlog.
Using the developers’ estimates and the customer’s feature priorities, the team lays out a release plan, mapping features very roughly to the first few iterations.