Project estimates are extremely difficult and important. Clients need ones they can rely on. They put them on their roadmaps. They make promises to their stakeholders based on the estimates. They budget according to them. There's always a pressure for the estimates to be low (cheap), yet accurate. At the same time we never have enough information about the project. This is the crux of every project. That's the intersection of plans, expectations, priorities, assumptions and uncertainties. How do you handle all that?

Note: This is a 2nd part of my series on skipping parts of Scrum. Click here the first one about lack of retrospectives.

Use ALL The Information! Include Everyone On The Team.

To make realistic plans the team needs to use all the information they have available. Descriptions, specifications, user stories, oral explanations and so on. That’s given. They also need to tap into their previous experience and knowledge gained both in- and outside the project. We need all the team's wisdom and experience to handle the huge uncertainty in real life projects. That's why Scrum requires that the team to arrive at a consensus for each task being estimated.

This is typically achieved with planning poker. During the planning session everyone on the team throws a card with their estimate onto the table. This way we reveal different perspectives on the task at hand. We can have an informed discussion to understand the optimistic and pessimistic estimates. Moreover we prefer to use Fibonacci sequence numbers for estimate effort: 1, 2, 3, 5, 8, 13, and so on… That helps to counteract the fact that the bigger the chunk of work, the harder it is to estimate.

Intent Behind Planning Session

1. Handling uncertainty. There’s never complete information about the work ahed. It’s full of gaps, uncovered assumptions, things we learn as we go, personal biases, etc. The client doesn't fully know what they need and the team is never sure how the solution will work out. They're both learning. That’s reality and trying to manage it with “complete specification” and “100% certain estimates” is denying it. The estimation is a way to learn if we even have a shot at reaching the goals.
2. Agreeing priorities. Unless we have a thorough planning session with the participation of the customer it can happen that something else is considered important by the team and something else by the client. So the team may focus on the stability of the backend, whereas the client needs a working demo for marketing department.
3. Scope & quality management. As the project progresses everybody learns: the team and the client. They learn about the technology and the business domain. They learn each other. They uncover the parts that have ben invisible at the beginning. This inevitably leads to changes in the initial scope. We either accounted for it or not. If not it means we have to give up on some features in favor of others or that we need to sacrifice quality for the sake of saving scope and date.
4. Improving accuracy. We should never forget that estimates are never 100% accurate. But well functioning team increases their accuracy of estimates over time. By keeping constant length of sprints and constant team composition the team builds an intuitive feel for how much they're able to deliver and how to estimate new tasks.
5. Expectation management. If work ahead requires 4 weeks and the customer expects delivery within 2 weeks someone is going to end up very unhappy. Either the client will miss their deadline or the team will work overtime to deliver the impossible. The sooner everyone knows about this difference the easier it is to manage it.
6. Limit ego. It’s natural for the group to look up to the most experienced or dominating person for decisions. And estimates are no exception. By doing a proper sprint planning every team member has a say and will be listened to. This downplays the role of big egos and HIPPOs (Highest Paid Person’s Opinion).

Risks Of Failing Sprint Planning

What can happen if we're not able to do a proper sprint planning? Here's an open list of possibilities:

• missed deadlines
• missed expectations
• undelivered sprints
• working overtime
• excessive pressure & stress
• frustration
• inability to plan & adjust.

Counteractions / Remedies

If you can’t approach estimation in the way expected by Scrum framework, try doing some of these:

• gather as complete knowledge (documentation) as possible
• get the client to spend some time together with the team
• keep communication channels open, so that information can be acquired when needed
• include many people into estimation
• add buffer time to your estimates
• moderate discussions and make sure everybody is heard
• keep your estimates written down and available for everyone
• compare estimates with actual effort; draw conclusions and adjust.

Summary

Poor planning is how plenty of projects screw themselves up before they even begin. That's why Scrum has particular practices around it. Want to have reliable estimates? Involve everyone in evaluation, keep a steady team and plan for constant time periods (sprints). The more information, points of view and communication around plans, the less unpleasant surprises for everybody.

Be sure to subscribe (RSS) or check back in a week for the next one.