Chapter 6: Planning and Estimating with Scrum

In the previous chapters, we examined the fundamental concepts and components of Scrum and obtained precious knowledge about them. Although this knowledge is essential, it is not enough to successfully deliver a software project. This is not a weakness on Scrum's part. It is simply that, as we have mentioned in previous chapters, Scrum is a framework, not a process or methodology. Scrum sets rules, responsibilities, and guidelines about how to develop software but doesn't dictate which methods or techniques to use.

Scrum Teams use different methodologies and processes for software development, and some of them have become de facto standards in Scrum. In this chapter, we will examine two fundamental concepts about software project management and how we can implement them in a Scrum-compatible manner. These concepts are estimating and planning. These are inextricably linked to one another; you can't plan without estimating...

Managing the art of estimation

Estimation is an essential part of software development and project management. Some people call it a necessary evil. I don't know about the evil part, but I certainly agree with the necessary part. The Scrum Guide doesn't say anything about how to estimate the items in our Product Backlog. However, the industry has adopted some techniques that we will discuss in the following sections. But first, let's examine why estimation is so important. Having estimates allows the Scrum Team to do the following:

• Prioritize items in the Product Backlog: This happens as part of the Backlog refinement process, which we talked about in Chapter 5, Scrum Artifacts. There are many ways to prioritize the items in the Product Backlog, and effort or size estimates are one way to do so.
• Choose which items to place in the Sprint Backlog: This happens during the Sprint planning event, as described in Chapter 4, Scrum Events. If we can't estimate...

Planning ahead with the product roadmap

There is a common misconception about Scrum and Agile methods in general: they don't apply or require any planning. Nothing could be further from the truth. Agile and Scrum both rely on good planning – it's a fundamental part of the Agile philosophy. The main differences between traditional planning and Agile planning are as follows:

• Agile planning happens regularly in an iterative and incremental manner.
• Agile planning prefers detailed short-term plans and abstract long-term plans.

We have already learned about the Sprint planning event, which happens at the start of each Sprint. In this section, we will examine how medium- and long-term planning is dealt with in Scrum. To learn about this, we need to understand what drives a Scrum product. So, let's discuss product roadmaps.

Envisioning the product journey with a product roadmap

A product usually begins its lifecycle as an idea or a vision. In...

Forecasting with velocity and burn charts

We can't really create any kind of plan without forecasting the impact of our work. For instance, during Sprint planning, we are called to decide on how many Product Backlog items we can work on during the Sprint. This is impossible to do without having some prior knowledge of our team's capacity or ability to deliver work. We usually employ the metric of velocity to forecast the work we can deal with during the Sprint. In addition, many Agile teams use burnup and burndown charts to track progress at any point during the Sprint. In this section, we'll examine these three metric concepts. Let's begin by understanding what velocity is all about.

Calculating team velocity

Velocity is a metric that specifies the average amount of Product Backlog items we can turn into an Increment during a Sprint. Having a sold estimation process, as described in the previous sections of this chapter, is essential in producing reliable...

Summary

In this chapter, we learned about estimation, planning, and forecasting. These skills are not part of the Scrum Guide and are not essential for passing the PSP I exam. However, they are skills that all Scrum Masters should possess to fully comprehend the product life cycle, and to best be able to provide leadership and counseling to the Scrum Team.

Due to this, we learned about how to estimate with story points by playing Planning Poker or using estimation buckets, as well as the different ways we can tweak these methods to our needs and circumstances. We also learned how to create a product roadmap and how this roadmap helps us formulate our Product Backlog and group our work into themes and capabilities (or epics).

Finally, we learned how to measure and monitor our progress and forecast our future work using velocity and burn charts. In the next chapter, we'll discuss how to manage the work that takes place within the Sprint. See you there!

Questions

1. Developers have estimated a Product Backlog item at 8 story points. Which of the following statements is true? (Choose one answer.)

   a) The item will require 8 working days to complete.

   b) The item is likely to take more effort or be more complex than an item estimated at 5 points.

   c) The item is too large or complex to be completed within a Sprint.

   d) The item will require 8 working hours to complete.

2. In what ways is the product roadmap useful? (Choose the three most appropriate answers.)

   a) It clearly identifies priorities and initiatives that should be pursued to realize the product goal.

   b) It sets specific dates for software releases in order to focus and motivate the Scrum team.

   c) It communicates the product strategy to external stakeholders.

   d) It demonstrates to stakeholders how we are going to realize the product goal as a series of activities leading to achievable milestones.

3. What do estimation techniques such as planning poker encourage exactly? (Choose one...

Further reading

• Succeeding with Agile software development using Scrum, Mike Cohn, Addison-Wesley, 2009
• Introduction to the New Statistics: Estimation, Open Science, and Beyond, Geoff Cumming and Robert Calin-Jageman, 21 Oct. 2016