Agile planning is crucial but can also be challenging. Especially, when your team has never used relative values, such as story points, to estimate their capacity before. Therefore, they have no reference sum of points to continue with. Naturally, at first, the sheer estimation process will be bumpy and produce imprecise results. However, this is not the only challenge you and your team face when carrying out Agile planning.
Today, we will cover the following three aspects of planning in Agile. First, we will explain Agile planning and its benefits. Second, we will talk about the advantages of using story points over hours to plan the team’s capacity. And then, we will discuss the challenges Agile teams face when planning with story points for the first time. We will also discuss other issues your team can face both during and after the Agile planning activity.
What is Agile planning?
During the Agile planning activity, the Agile team estimates the effort necessary to complete work they will commit to in the upcoming Sprint. The team can express its capacity using different absolute or relative values. However, one of the popular estimations approaches uses a relative value called a story point. In the process, team members estimate each backlog item they declare to commit to and the sum of the points they assign to those items becomes the overall sum of story points they will take into Sprint.
The goal of Agile planning is not only to find out how much capacity your team has. It is also about knowing how much work your team can realistically commit to and remain engaged and productive over the course of a Sprint.
In this regard, Agile planning differs from Classic resource capacity planning where you match available resources to the tasks you have planned ahead. In this type of planning, you also need to carefully plan and manage resource skills throughout the entire project lifecycle to ensure all tasks are delivered in a timely manner.
What is the difference between team capacity and team velocity?
Velocity is a sum of story points assigned to work items your team has completed in the Sprint. The key point here is that you measure velocity in points per Sprint, not days in one Sprint. When you calculate average team velocity based on work (story points) your team has completed in previous Sprints (3 to 5 past iterations), you, in fact, find the team capacity.
In this regard, you could view team capacity as the factor that would help determine the number of product backlog items your team could complete in the next Sprint at a consistent burndown rate.
Moreover, when it comes to team capacity, the basis for estimation is the team’s projected availability for the future Sprint. Therefore, it is a crucial factor for understanding the team’s availability for upcoming Sprints and the number of backlog items it can commit to with regard to team members’ capacity.
Why Agile planning is important?
Planning in an Agile environment with story points helps your team understand and better estimate the effort required for work items delivery in one Sprint. By estimating a certain number of work items with story points Sprint by Sprint, your team members learn their real capability to deliver work items. Over time, they will build on their experience and make their effort estimates more accurate.
As a result, Agile planning using Story Points introduces some degree of predictability in an unpredictable Agile environment. In other words, your team gradually and empirically learns how much it can deliver over the course of one iteration making planning more predictable, and thus more efficient.
Your team’s knowledge and estimation accuracy increase as it makes progress in the project.
Predictive vs adaptive planning
In a Classic (predictive) approach, you try to foresee as many details that could impact your project as you can. Subsequently, you break down your project into smaller pieces, determine individual pieces’ outputs, allocate resources, and fill their capacity within a specific timeframe before you initiate your project. The predictive approach has very little tolerance for unforeseen conditions, situations, or anything you have not accounted for but could affect your project—in one way or another. Such a reality becomes especially true when you deal with new products and services.
On the other hand, the Agile (adaptive) approach gives more room to adapt to changes. But more importantly, it is much more forgiving in case of imprecise estimations. In Agile, under or overestimations are natural, while the velocity of your team will likely slightly vary every Sprint. Also, due to the adaptive nature of Agile planning, the result by the end of the Sprint may differ from the initial planning intent. There are different reasons behind it and we will explore them in more detail further down in this article.
Factors that can impact Agile planning
When planning tasks for Sprint, you consider any events that could impact the individual team member’s availability. These could be non-working days resulting from public holidays or personal absences. Other personal or work-related commitments that could affect the individual’s productivity are also important.
Agile planning with story points vs hours
In the relative estimation approach, team members work according to values such as story points, t-shirt sizes, or fruit sizes. When working with relative values, your team can focus on the effort they will need to devote to individual tasks—not how soon they can complete a certain backlog item. Furthermore, using relative values for estimations instead of absolute values like time can prove to be beneficial for your team in a few other ways.
Increases focus
Story points do not impose any task completion deadlines other than those that come with Sprint itself. So instead of worrying about impeding deadlines based on the individual delivery time declarations, your team focuses on meeting the Definition of Done (DoD) for their backlog items.
Boosts productivity
The capacity planned with hours, or man-days can make your team’s work inefficient. From a psychological point of view, as humans, we tend to fixate on absolute values, especially on deadlines. Imagine you have a developer who completed a 5-hour task in 2.5 hours. What happens next? Parkinson’s Law kicks in.
According to this law, a developer will expand their work to fill the time allotted for its completion. This could mean that they will either take longer than necessary to complete a task; procrastinate and complete the task right before the deadline; or spend the remaining time to fine-tune the backlog item that otherwise is ready for delivery.
In either case, the productivity of an individual might severely suffer
Encourages better understanding
The user stories estimation with story points process is teamwork. It means that every person on the Agile team, be it a programmer, UX designer, or writer, makes their estimations for each story individually. It is very likely that the number of points every member has assigned to a certain task will vary. Such a situation results in a group discussion where each member chips in their point of view.
For example, one team member has estimated a task for 5 points while others for 3. As the discussion carries on, someone raises an argument no one has not thought about earlier. Consequently, the value of a story decreases or increases, depending on the shared understanding of the story’s complexity. So the bottom line here is that story point estimation helps everyone on the team hear their colleagues out and better understand the task they are about to commit to.
Creates a common ground for every team member
The gradation of story points according to the Fibonacci sequence gives a better perception of the difference in effort required for tasks. For example, there surely is a noticeable difference in effort needed for the 5-point and 8-point tasks. But if you were to estimate them for, let’s say 6 hours and the other person would for 8 hours, the difference would not be so clear. Such an estimation could also point out that one person, perhaps a senior, simply works faster than the others.
For that reason, it would be impossible to find a group consensus on how long a certain task should take and then, expect another person to fit the timeframe. Furthermore, since the development team consists of diverse roles, it would be odd for a non-engineer to estimate the time for a programmer to develop a certain feature.
Mitigates psychological load in case of failure
Absolute estimations are hardly ever accurate, but so are the relative ones. However, the difference between story points and time is, again, psychological. When a developer works on a 12-hour task they do not manage to complete on time, it could cause some negative mental responses in them.
Story points, on the other hand, are not about time but the size of an effort. A 5-point user story can take 8 hours, maybe even 10. Or perhaps it will take less because the story turned out to be less complex than your developers thought. Here, the completion of the story matters, while the time (just like the amount of work, complexity, and risks) is one of the components that make up the story points.
Moreover, even if the assignee has under or overestimated the story, they do not experience the same psychological impact as if they had not met the deadline or had finished their work sooner.
How to do Agile planning with story points for the first time
We mentioned that Agile planning becomes more accurate with time as the team learns its limits. But what if your team has not worked with story points before and you have no story point-based team velocity results from the previous Sprints? You can still carry out Agile planning bearing in mind what follows.
Start with the gut feeling and previous experience
If you have no hard data to refer to, your team needs to trust their guts. Naturally, developers will be unsure how many story points they can deliver for sure—and it’s okay. Let them take stories, and estimate the effort they will need to complete them until they come to the conclusion they cannot commit to any more items.
Consider all the factors that impact your team’s performance
When the Sprint is over, you can sum up the story points your team has managed to complete and calculate the initial velocity. Be aware that, initially, your team will not deliver all of its stories. In fact, it will deliver as little as 10% of the stories they estimated during Agile planning, or even zero. Such an outcome is nearly certain for teams that have not worked in an Agile environment before.
Let’s say your developers have committed to 60 story points. As the iteration comes to an end, it turns out they completed 22 points. The meaning of this result could be twofold—the team will either deliver 60 story points next Sprint, or they will not.
On the one hand, the team could have overestimated its capacity. However, the outcome of the Sprint is also subject to many factors that might or might not happen again. These could be external or internal factors, like risks or sudden sick leave respectively. Therefore, you also need to consider the factors that shaped the Sprint before you assess the results and your team’s capacity.
Continuously improve and build long-term predictability
The initial estimations regarding your Agile team’s capacity might be very inaccurate. But what truly matters is that, in an Agile environment, story points are not hard-written milestones that one must meet at any cost. If your team does not deliver 100% of their declared capacity, it is still fine—as long as your team draws conclusions and tries to apply the “lessons learned” in future estimations.
After all, estimations are just guesswork. And although the “mis-estimations” will remain a staple of Agile planning, they will help you build long-term predictability. This way, your team will be able to estimate better when a given feature is likely to be delivered. The number of story points your team has managed to deliver will also help you identify flaws in the process that decrease your developers’ performance.
Plan for the team’s optimal capacity
Filling the maximum possible capacity of your Agile team can be very risky. On the one hand, you have story points that somewhat guide your team toward their potential capacity. On the other, there is a gut feeling of your team members who can be overconfident about the stories they declare to deliver.
In both cases, you need to account for activities that are not strictly related to the stories, such as meetings or bug-fixing. For that reason, you and your team want to find their optimal capacity which will allow for maximum productivity without feeling overburdened.
Agile planning vs scope of work for Sprint
The Agile team members plan the scope of their work which is their commitment that is meant to be observed and respected. But in practice, in certain situations, the tasks you have planned for Sprint will change while Sprint is still running. And that can impact your team’s capacity in a few ways.
Adding story points on the go
When planning and estimating backlog items, your developers may take only a few tasks that will not fill their capacity for the whole Sprint. When they have finished or are about to finish their current tasks, they will pick another task from the backlog (approved by the Product Owner) that supports the Sprint goal. In practice, it means that they will be gradually building their velocity by adding story points as they take new tasks from the backlog.
Taking additional tasks from the Sprint backlog
Despite your team’s best efforts in providing estimates, some of your developers might finish their tasks sooner than they thought they would. So instead of sitting idly, they could ask their Project Owner (PO) if they can take additional tasks. In case of approval, they will add extra work (estimated with story points) to Sprint. As a result, again, they will increase their capacity and, thereby, also their velocity.
Swapping a blocked task for another
In theory, tasks for the Sprint should be independent (as per the INVEST criteria). However, in reality, it is difficult to guarantee such independence because the team is not always able to foresee every possible aspect pertaining to the task. This becomes especially true when it comes to risks, which, just like time, are one of the components that make up story points.
Risks (uncertainties) can result from technical complexity, interdependencies, budget, and many more factors. Some of those risks might become blockers that could delay task completion or perhaps even block it for the entire Sprint. Therefore, in this case, a developer may ask their PO to swap a blocked task for another.
After all, the Sprint backlog is a living organism that should support the adaptive nature of the Agile planning process.
Handling additional requests
The Sprint Goal and the tasks that go in line with it are to help the team to maintain their focus throughout the Sprint. Yet, it is quite common for another project stakeholder to request delivery of an extra “it’s just a small task” after the Agile planning is complete.
In such a situation, developers and Scrum Master (SM) have the right to refuse and postpone additional task completion until the next Sprint. And since in reality, many “small tasks” often turn out to take more time than a developer can afford to devote to it, it should remain the PO’s decision whether to add such an ad-hoc task to the Sprint backlog or not.
The PO may also approve an additional task in case the Sprint goal changes mid-way the Sprint and the new task supports the new goal. Or, the PO has mentioned during the Agile planning that the team will receive a few ad-hoc tasks somewhere along the Sprint and they should leave some room for them.
Furthermore, even though additional tasks impact the team’s focus, the completion of them may be reasonable and hold business value. For that reason, the PO—again—may agree to add such a task to the current Sprint backlog, and thus, increase the total number of story points (increase the team’s velocity).
Please note, however, that the ad-hoc tasks should not jeopardize the tasks your team has already committed to. To ensure that your team does not have too much on their plates, it might be best to remove one of the tasks from the Sprint backlog to make room for an additional request.
Negotiating user stories
Developers can negotiate with their PO which tasks or stories they will work on during the next Sprint. Even though such an approach can affect the initial Sprint goal, developers may choose and estimate chosen tasks first, and then, come up with a goal that will contain all those tasks—as long as the new goal supports PO’s vision and reflects business value based on the Product Backlog.
Such an approach, however, largely depends on the Agile team’s maturity level. If they have been working in an Agile environment and developing the same product for a while, the tasks they will propose will meet the PO’s product vision to at least a certain point. But if your team is new or even relatively new, it is better to align the tasks with the Sprint Goal, rather than the other way round.
In the end, whichever direction you and your team choose might not matter that much if you manage the backlog well—your developers will be able to tell what your vision for a coming Sprint is just by looking at the top backlog tasks.
Agile planning: summary
In Agile, capacity reflects the team’s ability to deliver a certain number of story points by the end of the Sprint. When carrying out Agile planning, either during the Sprint planning or, partially, during the Refinement, you need to be aware that your team will not always be able to accurately estimate the stories at hand.
However, learning and adapting the Sprint Backlog on the go are part of the Agile world. And even though it can impact your team’s final velocity, your team will gradually build on their experience and make Agile planning more efficient and predictable.
Well, have you also got the interest in Agile Planning? We can help you implement Agile Planning and adapt it to your business needs. Contact us today to arrange a no-obligation consultation with one of our experts.
The following link will take you to the original blog article: https://bigpicture.one/agile-planning/
