In Scrum, the team has to estimate everything that is in the backlog. It is essential they know how much time each task or story is expected to take, so they can plan for whether the item should be moved to the sprint backlog.

The Scrum product backlog is a list of all the things that must be done for a project. These items can be just about anything, from technical items, to issues with the customer or user. The product backlog is the responsibility of the product owner, and the ScrumMaster and the development team contribute to it.

High Level Estimates

In order to understand the size of the items of the product backlog, it is necessary to provide high-level estimates. This helps when it comes to prioritizing where the items belong on the product backlog, and whether or not the possible features are worth the team's efforts.

But in the beginning, the team doesn't know much about the items in the backlog. They don't know what the features will do, and they don't know what must be done to take the feature to completion. The team also doesn't know how, exactly, they will implement the changes. So, the team has to take a high-level estimate -- basically, a guesstimate.

Estimating the Product Backlog In Points

So, how does the team make this estimate? The best way is to use points. In Scrum, they do NOT use units of time -- they use Scrum points. It is actually easier for a development team to estimate in terms of size, rather than terms of time. It is easier to ask, "How big is it?" than it is to ask, "How long will it take?" Product owners are clear that what the team provides is simply an estimate of size, not the time it will take to complete the feature.

Using the Point System

Ever heard of Fibonacci numbers? I will tell you that Agile and Scrum people LOVE Fibonacci.

In mathematics, Fibonacci numbers, or the Fibonacci sequence, are the numbers in the following sequence:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so forth.

In Fibonacci, the first two numbers are either zero and one, or one and one, and then each subsequent number is the sum of the previous two.

Math is fun, huh?

Estimate As A Team

An easy way to estimate as a team is to use cards. Have every team member put their estimate on a card, and then everyone show their card at the same time. This way, all members are engaged and on the same page. Once all the numbers are shown, use them to negotiate a final size for the backlog item.

This team estimation exercise can be done during the daily Scrum meeting.

Team Velocity

You know what velocity is when it comes to speed, or to your car. But velocity also applies to development teams, and how quickly they complete work. Team velocity is the rate that a development team delivers tasks and stories from the product backlog. If the team knows their velocity, then they will know:

• How much value they've delivered thus far

• When they'll be able to deliver all stories in the backlog

• How many story points can be delivered by a particular date

How is velocity calculated? Again, let's use some math. A team delivers three user stories. The total story points are 20, and therefore the velocity is 20.

Next time, if the team delivers 30 story points, then the velocity is now 25 (the average of 20 and 30). Velocity is the total number of story points that a team completes during an iteration.

Velocity is needed because is can help the team:

• Predict how much work can be delivered by a particular date

• Predict a date for when a certain amount of work must be done

• Realize their limits when determining amount of time the team can commit during the sprint

There are things that can happen that can affect the team's velocity. These are:

• Roadblocks

  Interested in learning more? Why not take an online Product Management course?

• Motivation

• Lack of experience

• Environment of development team

• Transparency

• Project goals

• Routine processes

• Product problems

If a user story is incomplete, it cannot be counted in the velocity. Velocity is determined by work that is done and delivered. Plus:

• The team cannot determine how much is ready -- it would be a guess.

• It could lead to a false sense of accuracy.

• If the story is incomplete, it provides no value to the customer.

Take a Look at Priorities

Once the team has estimated the backlog, it is time for the product owner to take a look and determine what the priorities are. Seeing the estimations might spur them to move certain tasks up the list, and others down the list.

Burndown Chart

The best way to track progress in Scrum is with the daily burndown chart.

Key Term!

Burndown Chart

A burndown chart is a graph that shows how much work is left to do, versus how much time is left to do it. The backlog is on the vertical axis, and time is on the horizontal axis. It is a great way to predict when all work will be completed.

Using Agile Principles

In the Agile framework, there are principles that will highlight problems early on in the development process, while there is still enough time to fix them. In waterfall and other traditional software development methodologies, all testing is done at the end, at one time. This can be dangerous, since you have no idea how many bugs the team might find.

In Agile development, the testing is done through the product lifecycle, and when a feature is done, it is truly "done." The product owner is also able to see the product frequently enough that he can help guide its development completely.

Daily Burndown Chart

The daily burndown chart is a great way for teams to estimate how much time they have left to complete the items that are on the backlogs. It is a very easy tool to use, and very valuable for the development team.

When using the chart, the team will end up with the "estimated time to complete," or ETC. The team then uses this figure in the sprint backlog, and it should be updated on a daily basis. Each team member should track their own ETCs and be able to present them during the daily Scrum meeting. If it's done daily, there should only be a few items to update each day.

The goal for the team should be for the team to have zero hours left by the end of the sprint. Using the burndown chart gives a visual representation of time left, which, when placed in a visible area, is helpful for the entire team.

Also, as the team progresses through the sprint, they should chart the actual time the tasks are taking, and plot that alongside the estimate. Not only will the difference motivate them, but it will help in future iterations and estimations.

The team should also take notes and post them on the graph, as well. The notes should discuss any key events that happen during the sprint, especially in relation to the estimations. This is a great way to save important events, so they are not forgotten when it comes time for the sprint review meeting. These notes could also prove interesting to management and the stakeholders.

The burndown chart will show the team whether they are on task, but it will not help them fix any problems that might come along the way. If this happens, the chart is still a good way to try to stay on task, and learn for future sprints and estimations. Seeing the problems in front of you makes it much more difficult to avoid them.

Managing Quality

There is no point in spending time and money on a product, if the product will end up being of poor quality. So to prevent this, quality assurance (QA) is a built-in part of the Scrum development team.

Quality management in Scrum allows customers to be aware of any project bugs or errors, and helps them determine whether the project will still work for them. In the Scrum methodology, quality is all about the satisfaction of the customer, and the final product being a success.

In Agile and Scrum software development, quality management is determined using a three-step process.

Quality Planning

Quality Control

Quality Assurance

One of the first principles of Scrum is to develop the features with the highest priority first. Features that are less important will be done in subsequent sprints, or even left out all together. This allows the development team to focus on the quality of the feature.

One of the best reasons to use quality planning is that it reduces technical debt. Technical debt is the work that the team places at a lower prioritization, so they can continue to develop the product. The problem is that technical debt accrues, and like any debt, must eventually be paid in the future.

Some of the causes of technical debt are:

Quick-fix deliverables that do not stand up to normal standards of quality or security

Incomplete or undone testing

Incorrect documentation

Lack of coordination between team members

Lack of sharing of business and technical knowledge with stakeholders

Placing too much focus on short-term goals, instead of the long-term goals of the company.

In a Scrum project, technical debt cannot be carried over through a sprint, because the goal of the sprint is to deliver a finished product. The product must be able to be classified as done.

Key Term!

Acceptance Criteria

The conditions that a product must satisfy in order to be accepted by a customer, a user, or a consuming system

To keep technical debt at a minimum, it is important for the team to clearly define the feature required from the sprint, along with any acceptance criteria. Determining what the acceptance criteria is an essential part of quality planning and it is required for proper quality control.

Technical debt can be a big problem in some project management techniques where development, testing, etc., are done sequentially, such as in the waterfall method. In these cases, the actions are performed by many different people, and no one person is tasked with a working deliverable (a product).

Because of this, technical debt accrues and that leads to higher development and release costs in the final cost of the launch. Costs at this stage are higher, since the product is nearing launch time. In Scrum, these issues are prevented, because deliverables and acceptance criteria are a part of the sprint backlog, and must be completed at the end of the sprint.

Integrating Quality Assurance Into Scrum

Scrum doesn't detail how to integrate quality assurance (QA) practices into the software development process. This is because Scrum works in short-term sprints, and QA simply doesn't work that way. Here are four ways to incorporate QA processes into Agile and Scrum.

1. Understand the Scrum/Agile principles regarding testing.

In the Agile Manifesto, it states, "Deliver working software frequently, from a couple of weeks, to a couple of months, with a preference to the shorter timescale," and "Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together."

When working in Scrum, you must adhere to its principles, and however the team chooses to use QA should reflect these principles. The team cannot test features from one sprint in another sprint; that is not how Scrum works. So when deciding how to add quality assurance, make sure the Scrum framework and principles are adhered to.

2. Find and remove any impediments to Scrum values first.

When first using Scrum, there will be issues that cannot be fixed in a single sprint. It is easy to just ignore Scrum, but don't do that. Scrum will expose flaws in the development process, and the team might try to work around these flaws.

The goal should be to remove anything that will keep the team from sticking to the Scrum values.

3. Test as you go along.

It is important that in the sprint, quality assurance works alongside the team, so they can have the same knowledge about user and customer expectations as the developers have. This way, they can start building test cases early in the development process and evolve those over time.

Since sprints are so short, corroboration between the team and QA can determine a way to test feature elements before the sprint is completed. This way the QA analysts can be involved throughout the process and continually test their cases. When the user story is completed, the final round of testing should take less time since QA has been testing all along.

4. Understand it takes time.

Transitioning to Agile and Scrum is a journey. It is an easy framework to learn, but a very difficult one to master. There is a great deal of trial and error, and trying to figure out what works, and what works for the development team.

In the beginning, it might be difficult to adhere strictly to the Scrum practices. It will take time to work up to perfect adherence. Over time though, quality assurance testing can be adapted, and the amount of time needed to test will be cut considerably. Each sprint will require less and less full-on QA testing.

Key Term!

Quality Assurance

Quality assurance is the maintenance of a pre-determined quality of a service or product, especially when trying to meet that quality through the production process.