Introduction
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 :
- What is the scope of the work?
- How long will it take to deliver?
- How much will it cost?
- When do we have to deliver it?
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
- What is Agile Estimation and Planning
- Levels of Agile planning
- Agile estimation techniques which Agile teams can use in their projects
What is Agile Planning?
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:
- Delivery or increments happen in iterations / sprints : Basic building blocks of an agile plan is a defined duration called iterations, where teams plan work based on their capacity and deliver it to get feedback and this repeats during the course of the project
- Work items ( Features / stories ) which deliver greater value has to be prioritized first. – Release features which will add more value to the customer first and within the feature, user stories which have high value to be delivered in the first few sprints. Basically teams are constantly looking to deliver what the customer / user wants as early as possible
- Consider the room for changing priorities and uncertainties : Agile teams need to ensure that the changing priorities / requirements will need to be addressed. Having a concrete plan and not adapting to the changing needs does not fit into the value of adapting to agile itself. Also, there needs to be proper understanding of the dependencies / uncertainties in the work items and we need to plan our mitigation of risk
- One Team Estimation and Planning : Since our delivery is continuous, our planning also becomes continuous. We will have to move away from the concept of leads and architects giving a high level estimation and making a plan out of it. Involve the doers ( development team members ) right from the stage of understanding the requirements, estimation, planning till the execution phase.
Levels of Agile Planning in Agile
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.
Vision/Strategy
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.
Portfolio Planning/Roadmap Planning
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.
Product Planning/Release Planning
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
Sprint Planning/Iteration Planning
Sprint planning is basically development team activity which is done to plan a set of user stories prioritized by the product team for an iteration. Usually the PO sets the direction to the team on what is expected from the team based on customer/user need in terms of user stories. The development team use planning poker estimation techniques to estimate the stories and based on their capacity/velocity, they commit to deliver an increment to the product
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 Stand up/Daily planning
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
- What did we achieve yesterday?
- What are we planning to achieve today?
- What are the dependencies
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.
Fibonacci Series, Planning Poker and Story Points
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
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.
- Effort taken by the entire team
- Complexity of the work
- Uncertainty in the story
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.
Fibonacci Series
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.
Planning Poker
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
- Teams pick the smallest story from the backlog which is easiest to implement, no uncertainty, and least effort to implement and identifies it as “Base Story”
- Teams pick a story to be estimated and first have a discussion around what is the work, what is the approach and technicalities along with dependencies and uncertainties
- Next, the team has the fibonacci series with them and are asked to give a number for the story after discussion and their understanding on the effort, complexity and uncertainty. The question asked here is “How big is this work when compared to the “Base Story”?
- Then the team members are asked to show their values
- Story point is then decided based on 3 scenarios
- Bingo – Everyone in the team gives the same number. Then story point is the number given by the team
- Neighbors – If the minimum estimate we have got from the team members and the max estimate we have got are neighbors in the series ( Eg: Dev 1 = 5 , Dev 2 = 3) we go with the max number giving the benefit of the doubt
- Non Neighbors – If the minimum estimate we have got from the team members and the max estimate we have got are not neighbors in the series ( Eg: Dev 1 = 5 , Dev 2 = 2 ) we go with the max number giving the benefit of the doubt, in this case we have another round of discussion and take consensus from the team
Conclusion
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 “consult@benzne.com” for any suggestions or feedback.
Sujith G
Agile Coach – Benzne
