Planning a sprint in the right way

Overview

A very frequently asked question is “How much to pull into the sprint during sprint planning?”. It doesn’t have any answer in Scrum framework, this is more of tool-technique and strategy related question.

Planning a sprint is one of the main task of the product mangers and naturally, they want to pull as task as possible but this must be agreed by the entire team who made to develop task. An easy goal produce a non productive team. A impossible goal produce a demotivated team. How add task to the sprint correctly?

Quantity as unit measurement: some teams add to sprint X quantity of task. The problem with this method is obvious: different tasks take different time. In addition, is stressing for all the team manage an “Emergency task” when it became a routine. Having “Completing task” as a goal is for a programmer as “winning races” is for a F1 driver. They are certainly not real goals and they have not any sense.

Estimate in Hours: other frequently technique is to measure task in hours. It measure each task separately in hours worked. One working week have 40 ours so we can add 40 hours for each person. Isn’t it? Persons are not machines. Some days people are tired and some days people are inspired. People takes free days and need a coffee break between tasks. People get experience with the environment across the time and frequently they move team. In addition, people are not good to estimating task because exist problems like as technical debt, unexpected bugs, definition of done, or simply they have a bad day.

Using Fibonacci points: this method is no different from the previous one. It is a good starting point at comparing two task but it do not resolves the main problem at all. This method makes estimations so abstract and move away from reality.

The Parkinson law

All of this techniques hides something. By defining a goal as “completed task in the iteration” programmers can take more time that they really need to complete a task. I’m not talking about lazy programmers, but about a condition inherent in the human brain. The Parkinson’s law says “work expands so as to fill the time available for its completion”.

Imagine the situation that a programmer have to do the last task in the iteration and this is a very easy one. Programmer knows that available time before finish current iteration is 3 days. How many time would take to complete the task? I am sure it take all available time: 3 days. Remember that you can failure in two different modes when you estimate. Finish later than due date is a problem, but finish earlier is as bad as be behind the schedule.

To avoid “to failure” and justify estimations, programmers prefers to use more time that they really need and enjoy three relaxed days. It seems that the productivity is not at 100%. Fans can say that it was not analysis enough but in any way estimate is about the future, is an approximation, and never will exact.

Changing the paradigm: be goal oriented

The main objective is to satisfy the customer. At the end of the day, he is the one who pays us. The first principle of the Agile Manifiesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. So, we must be goal customer oriented.

I can not use a Fibonacci point to build a goal because is not a customer goal. I can not say to the customer “This month I push 50 points”. The customer does not know anything about story points because it is not his objective and it should not be ours.

In order to define a good sprint goal as a Product Manager we have to listen the customer and satisfy (sometimes partially) his goals. We must to be able to image the software status once the iteration ends. It is very important to communicate it to the entire team.

And finally we should to add to the iteration only activities that are aligned with the sprint goal. But, how many activities? It is very difficult to answer. But there are some rules to respect:

• All team must agree
• A necessary amount to meet the sprint goal
• A sufficient amount to satisfy the product owner
• Just the right amount to motivate the whole team

Using this approach add to the project many vantages. The most important thing is that technical team and business team are aligned (4th rule of agile manifesto). Entire team save time allocated for the estimation meeting (and more time can be used to go ahead).Tip: Define the objectives of the next two iterations to carry out your vision to the entire team so that they work with one goal in mind.

The biggest success is satisfying the customer at the end of the each iteration. When customer is happy time is not a problem. In order to increase productivity, Product Managers should be focused about how to motivate developers instead of optimize the sprint planning. A programmer well motivated works faster and this positive energy motivate all team.

The cost of estimations meetings can be more expensive than you can imagine if do not timebox it. The cost of adding a some more tasks that can be developed is near zero because the goal do not depends of the quantity task in the “done” column and the uncompleted task must be included in the next iteration.

Conclusion

I described how to planning next sprints using the goal-oriented product roadmap. I think is better in the most situations when we build software in 2020. Using customer goals the software trend to be more aligned with the business team. It is useful to think in a horizontal way. Plan goals oriented is perfect when is a well-know software type like an e-commerce. In addition, starting with the goal in mind is one of the 7 habits of the hight effective people.

The story map strategy use to moves the software to the technical side and it is easier to make the vision shorter encapsulating it at the current story. This is a good strategy to aboard iterations that are core business rules related, usually unknown for most people. For example, like developing an email-marketing software or an F1 race team control panel.Personaly, I often plan iteration using the goal-oriented strategy and occasionally I switch to story map strategy when the software lifecycle is solid and older.

But what about tracking the tema productivity? That, in the next article.

Resources

• Tips for Agile product roadmaps & product roadmap examples
• Parkinson’s law — Wikipedia
• Scrum 19 sprint planning anti patterns
• Official Scrum guide
• 7 habits of the hight effective people (By Stephen R. Covey)