Planning is an essential, inevitable and very first phase of any project be it a conventional project or an Agile Project. The basic idea behind planning any software project is to find answers to some basic questions like :
With the industry and technology evolution over the years, ever increasing competition , constantly changing customer needs, and the need to get feedback as early as possible, our conventional ways of project management or project planning may not be suitable. This is the reason why companies adapt to Agile software development. Where the planning is expected to also change as per the customer’s changing objectives.
This blog aims at explaining the following
The industry evolution has pushed us to change our product development with continuous deliveries, adapting to changing priorities, iterative and incremental deployments etc. This necessitates us to change our ways of planning to accommodate this new reality. We need to start looking at delivering in smaller chunks with just enough planning leaving room for uncertainties versus upfront, in-depth planning at the start.
Before we go deeper into the levels of planning in Agile , all Agile teams including Product owners, development team, scrum masters, team members need to understand a few basic principles or parameters about agile ways of working. Mike Cohn in his book of “Agile estimation and Planning” explains in detail the basic understanding Agile teams need and they are as follows:
Imagine a big organization or a company which deals with a lot of portfolios or products.. They can get huge requirements, or initiatives or even a new product itself for a portfolio. The requirements itself can be of different sizes and with these huge requirements, product ideas may need a lot of teams to work simultaneously with a common goal. The challenge which arises is how do we connect , collaborate and plan for multiple products with multiple teams and also how do we ensure just enough planning which Agile promotes?
To accommodate such needs, agile recommends 5 levels of planning at different stages or unit areas. The below picture represents a flow or breakage of planning at different levels.
The first step/level of planning is to identify the vision of the product itself. What is the product we are trying to build, for whom are we trying to build? What is the outcome we are trying to achieve in the long run?
This helps to identify the goal of the company and what set of products we will need for which set of users/countries. The outcome of this planning is the set of products which we will have to deliver for a set of users. Basically the list of portfolios for the organization. The best way to identify the vision is to use a simple technique called “Elevator Pitch Technique”.
This level of planning sets the tone and the direction for the organization and is usually revisited / modified every year or once in 2-3 years.
Once the Vision is published, and portfolios are segregated based on the value streams, it is time for each portfolio owner to plan the list of products which will have to be developed to achieve the bigger goal.
The outcome of this planning is the list of products which a particular portfolio will have to be developed in order to cater to the vision. We often see new initiatives or a new product idea coming out of this planning and this is usually revisited/modified/updated every year or sometimes even in 6 months.
Release planning starts with deriving the product backlog, identifying the epics , breaking the epics into user stories and slicing the release as “NOW”, “NEXT” and “LATER”, basically defining the features into milestones based on the customer priority.
Development teams use T shirt sizing and planning poker estimation to estimate the epics and user stories which is a relative way of estimation. A milestone or release can span across months, e.g. a milestone can be of one month duration or even 3 months duration and this level of plan is revisited/modified/updated every month or quarterly
Usually the sprints span from 1 week to 4 weeks and this planning is revisited / redone before starting a sprint, where the outcome of this planning is the sprint backlog for the team.
Daily planning is again a team level planning which happens almost every day during the sprint execution. The team collectively checks the progress made in the sprint, discusses the dependencies and plans the work for the day. Teams do this by answering 3 questions
Estimation in Agile
Let’s understand the basis of estimation when it comes to conventional project delivery vs agile project management. When it comes to conventional project management, we usually have one delivery at the end of the project cycle. With this, the question behind estimation is to validate the timeline and the budget variance at a project level. And the estimation is primarily used to answer the question “How long will we take to deliver this feature”. Hourly Estimates were mostly used by the teams while estimating the projects earlier and hourly estimates represent the commitment of the team with a delivery perspective and usually the estimates are provided by the Leads and Architects and is pushed upon the teams
However, when it comes to agile ways of working, we have incremental delivery every iteration or even continuous delivery sometimes. So with this the idea behind the estimation changes to understand the size of the work and which sprint / release can it fit into?. And the estimation is primarily used to answer the question “How big is this work?” , “Which Sprint can it fit into?”. Usually agile teams use story point estimation/T-shirt sizing for estimations which does not talk about commitment but rather the size of the work. The estimations in agile set up is usually done by all the development team members. Development teams identify the work, understand the stories/epics, discuss, mark the dependencies and then estimate it based on the output of planning poker activity.
A good estimate is one given by the development team (Doers) after understanding the requirement clearly, understanding the uncertainty/dependencies and an agile estimation like a Story point is a number given by the entire team.
Story point is simply a number given by the entire team which signifies the size of the work. Story point estimation is a relative way of estimation i.e teams compare one work with the other and then size the work based on the 3 factors mentioned below.
A smaller story point signifies the work for the team is small and a bigger story point signifies that the work is big in size for the team.
Teams while estimating a user story with story points use a series of numbers called Fibonacci series and the series goes like this 0, 0.5, 1, 2, 3, 5, 8 , 13, 20, 40 and so on. Why Fibonacci series is used in estimating a user story – There is a reason why teams use fibonacci series, that is to estimate uncertainty. If you closely observe the series, there are gaps between numbers and the gaps increase as we go higher in the series. These gaps represent the uncertainties in the story. A user story with a higher amount of uncertainty is estimated with a higher number from the series.
This is one of the most used estimation techniques used by the teams while estimating user stories. Here’s what happens in the planning poker technique
Agile planning is nothing but planning a project / product with a just enough approach but also keeping in mind the changing priorities from the customer, delivering smaller chunks of work frequently, planning collaboratively, and keeping an eye on the uncertainties.
This brings our blog on “A Beginner’s Guide To Agile Planning & Estimation” to a conclusion.
Please reach out to “email@example.com” for any suggestions or feedback.
Agile Coach – Benzne