Agile Planning: A Beginner’s Guide To Planning & Executing Iterative Projects
With more customers looking at reducing project risks and realizing value faster, more teams are adopting agile methods. According to a PMI survey, over 70 percent of businesses report using some form of agile to plan and execute projects.
In this article, we’re going to guide you through the concepts of agile planning. We’ll look at how you can structure and execute your projects in a way that delivers great results!
Specifically, we’re going to give you an insight into:
- What is Agile Planning?
- What are the Levels of Agile Planning?
- Tips for Planning Projects, Sprints & Daily Tasks
- Agile Planning in Toggl Plan
So, if you’re looking to increase your knowledge of agile ways of working, as well as hear some real-life examples, this article is for you!
Well, what are you waiting for? Let’s get started!
What is Agile Planning?
Traditional project planning follows a ‘big bang’ approach whereby all of the change is co-ordinated and delivered at one fixed time. This often comes at the end of a project, after a lengthy period of detailed up-front planning, designing, and testing.
The agile planning process provides a more iterative approach. By delivering the project in smaller chunks, customers can realize the benefits quicker.
It might be easier to explain in an example… so here’s a case study!
Imagine you’re running a project to build a website. The website has 10 different pages, each serving a different function.
The development team estimates each page will take one week, meaning your website will take 10 weeks to build.
In traditional project management, you would only put the website live once all 10 pages have been completed. This would mean waiting the whole 10 weeks before your customers could get any value from your website – that’s way too long!
When applying agile principles, you may structure your website project to deliver two pages every 2 weeks. The project will still take 10 weeks to complete of course. But after only 2 weeks your customers can start accessing the website and start receiving value!
This is how it may look at the project-level, but how does this fit into the wider business landscape?
When making changes at pace, it’s important to plan effectively. The agile planning process happens on 6 different levels, and is often referred to as the Agile Planning Onion. Let’s take a look at how it works!
1. Strategy Planning
This level of planning will usually be conducted by the senior leadership team. Here they’re laying out the strategy for the organization; specifying how they’re going to achieve the corporate objectives.
For example, the senior leadership team in a retail organization decides to invest in a new digital strategy. The goal is to increase revenue by 20%. This strategy is long-term and will be realized over the next 2 years.
2. Portfolio Planning
At the next level down, consider how to plan out the portfolio of products/services to achieve the strategy. Again the responsibility lies with senior members of the organization, typically at the head of department level.
Based on the strategy, the different portfolio teams come up with ways to make purchasing faster. The digital team decides to introduce a new mobile app to its portfolio. This will be a great way to connect customers to a new buying experience from home.
3. Product Planning
Here, plan how the product will evolve and change in the medium-term. This level of planning will start to involve team members such as Project Managers, Product Managers, and Research Managers to understand the roadmap for change.
A product team is assembled for the new app. They use market research to devise a roadmap of features for the app. They spend time planning out, at a high-level, the effort for each feature, and which ones to deliver over the next 12 months.
4. Release Planning
With the roadmap of changes identified, then manage how to release those changes to the customers. Set the business framework for that to happen. Here, Project Managers/Delivery Managers work with technical leads to plan the processes to support technical release.
Technical teams assemble to place structure around the deployment of the initial app features. They also plan ahead, detailing how they will manage the integration of further features moving forward. They’re planning in 2 monthly cycles for each release.
5. Iteration Planning
This is where small teams of developers/designers/testers really start to come together. An iteration, sometimes referred to as a sprint, is a single period of time to make the changes. Here, the planning is somewhere between 1-4 weeks ahead and will involve all team members understanding what needs to be achieved in that time.
Based on the first targeted release in 2 months’ time, the team breaks down the features from the product roadmap and divides them into development iterations. These will be 2-weekly, with set sessions scheduled to re-plan and assess performance at the start and end of each iteration.
6. Daily Planning
When working through iterations, plan for the day ahead. To do this you must understand what each team member has achieved, what’s on the schedule for the next day, and assess any problems they’re currently facing.
Each day, the team will get together to communicate their individual progress towards the completion of that iteration. Each team member can input what they have completed, what they have left to do, and raise any issues. It will be the role of a Project Manager/Delivery Manager/Scrum Master to facilitate that session and ensure progress remains on track.
When using Toggl, you’ll probably focus on Levels 3, 5 & 6 of the onion.
Let’s look at some of the common methods for planning and executing at each of these levels.
Level 3 Agile Planning – Building a Product Backlog
Level 3 of the Agile Planning Onion is all about planning at a product level. Specifically, this is where we identify and plan the features we want to bring to our product.
There are multiple techniques you can use to build a product backlog. Let’s look at exactly what a backlog is and how you can start building your own!
What is a Product Backlog?
A backlog is a list of changes, new features, bug fixes, or any other activity that a team might deliver.
To build a backlog, you need to add each feature as an individual ‘backlog item’. As you add items into your backlog, you need to do three things:
- Define the backlog item
- Estimate the backlog item
- Prioritize the backlog item
- Using User Stories to Define a Backlog Item
Backlog items are the requirements of customers or stakeholders. They are often written in the format of user stories.
A user story captures the description of a software feature from the end user’s perspective. They can be written in different formats, but the most common is the ‘who’ ‘what’ ‘why’ format. Here’s an example:
- “Who” – As a website user
- “What” – I want to login to my account
- “Why” – So that I can view my orders
At this stage, you should keep your requirements broad. The exact detail will be defined during the development iteration.
The process of defining requirements is often undertaken by a Business Analyst or a Product Owner. In practice, requirements may come from customer feedback or customer-facing team members, e.g. Customer Success Managers.
Once you’ve got your list of requirements, it’s time to work out how long each will take to deliver.
With your backlog defined, it’s time to estimate exactly how long each item will take to build.
There are different ways to do this but two of the most common methods are:
- T-shirt sizing
- And, Agile planning poker
Here’s how they both work:
‘T-shirt sizing’ uses familiar terms from clothing to understand the size of a requirement. As a team, you have to estimate if a requirement is a small, medium, large or extra-large piece of work. There will need to be common effort metrics underpinning your sizes. For example, you might agree beforehand that a small piece of work is equivalent to 2 days effort.
‘Agile planning poker cards’ work in much the same way. But instead of using t-shirt sizes, you’ll use the numbers on playing cards. As with t-shirt sizing, you need to agree on how much effort each number represents e.g. a number 4 may represent 4 days effort.
How Does Agile Estimation Work In Practice?
The Business Analyst/Product Owner gets the team together for an estimation session.
Read each user story out in turn. Each member of the team then writes down their opinion of the t-shirt size or shows the card they believe its worth.
There will probably be differences in opinion! As a group, discuss your thoughts until you come to a consensus.
Each user story will now have a documented estimation. Be sure to also capture any stand-out notes detailing why it is that size.
Great, you’ve now estimated all your user stories!
Prioritize the Backlog
You’ve defined the user stories and given them an estimation. Now the final question you must answer is: Which one do we do first?
For this, you need to prioritize each item to understand what will bring the most value.
Unfortunately, prioritization isn’t an exact science. The reason a certain user story may be more important than another will be unique to your business.
Here are some questions to ask yourself when prioritizing backlog items:
- How much value will this bring our customers?
- How many customers receive that value?
- Could this item directly increase business revenue? If so, by how much?
- Does this item fit into our long-term strategy?
- What are the costs to build this item?
- However you chose to prioritize, you now arrange your backlog items accordingly. This helps answer the question of which item(s) to do first!
Managing your backlog isn’t a one-off task. As a product team, you need to constantly add/update/remove items as customer and business needs change!
So, that’s planning at Level 3 of the Agile Planning Onion. In practice, there’s a lot more to mastering the process – but these are the high-level principles.
Product Level Agile Planning in Toggl Plan
Creating a product backlog is super easy in Toggl Plan – here’s how it’s done:
Step 1 – Create a new plan in Toggl selecting the ‘Boards’ view to begin creating your own agile planning board. Give it a name you’ll easily recognize, such as ‘Website Product Backlog.’
Step 2 – Create some custom statuses. We’ve gone for ‘Backlog’, ‘In Progress’, ‘Ready for Release’ and ‘Done’, but create what works for you.
Step 3 – Start creating tasks against your backlog status. Give each task a unique number and name, use tags to record your size estimation and prioritization, and utilize the notes area to put the detail of the user story.
Step 4 – You can now view all of your backlog items in one place. Remember you can drag and drop them into the correct order as well as using the filter tags function to sort further.
You’re now a backlog expert and you’ve got it all set up in Toggl!
Level 5 Agile Planning – Planning a Sprint
With product-level planning complete, we can move onto planning at Level 5 – iteration planning!
Iterations are commonly known as sprints within certain agile frameworks and we’ll use both terms interchangeably.
Before committing to delivering backlog items, we have to answer the following question: How much work can be achieved in this iteration?
Understanding Sprint Capacity & Velocity
As your team matures, you will understand exactly how much work you can achieve in a certain time period.
When answering the question of ‘how much’ there are two different terms thrown around: capacity and velocity. Here’s what they both mean:
Capacity – When planning your iteration, understanding your team’s capacity means looking ahead to see what each member can achieve. Here, you’re looking for events such as holidays, long-term illnesses, and training days. You need to identify events that may prevent work from being completed.
Velocity – For mature teams, velocity looks back at how much work you’ve been able to complete previously. If we cast our minds back to t-shirt sizing, we may say the velocity of our team is equivalent to 3 ‘large’ items per iteration.
So, as we begin to plan our iteration we can look forward (capacity) and back (velocity) to understand what we can achieve.
Let’s take a brief example:
You’re the Project Manager working with a team of 5 people to plan your next iteration. From previous iterations, you know you can typically complete 10 small-sized work items per iteration.
You look at the calendar. You notice one of your team members will be on holiday for the whole iteration. This means your team capacity is down to 80%.
Therefore, when planning forward you should also adjust your capacity down to 80%. This means you will only commit to 8 small-sized items for this sprint (10 x 80% = 8) instead of 10.
Sprint Plan Meeting
So far, you have prioritized items in your backlog with associated time estimates. You have also forecast your team’s capacity.
Now you need to marry up the two during a formal sprint planning meeting.
As a team, select which backlog items you can complete in this iteration. To avoid missing deadlines don’t exceed your capacity allowance.
Once the backlog items have been selected, you’re ready to go!
Sprint Planning in Toggl Plan
There are different ways you could manage this in Toggl depending on the size, scale, and complexity of your team.
Here’s a simple way to set up your sprint!
Step 1 – Bring your team together for an iteration planning session. Get your Website Backlog Plan up for everyone to see.
Step 2 – Once you have selected an item, open it up on the task view.
Step 3 – From here, update the item. Change the status to ‘In Progress’ and assign attributes such as segment, assignee, and from-to dates.
Step 4 – You can also add further to-do activities. This will help you better track its completion.
Step 5 – Now you have a view of which items have moved from your backlog ready for this iteration!