In Chapter 3 we took a look at different development processes and frameworks. Our experience is that we have seen a great deal of improvement in projects over the last few years. To be more specific, we have seen that the agile influence is making an impact in how our projects are delivering business value.

The focus of this book, when it comes to processes and frameworks, is on Scrum and XP. Partly because we like these ourselves, and partly because Microsoft focuses hard on implementing support in Visual Studio and TFS for these practices. Microsoft for example, includes a great template for running Scrum projects straight out of the box. We will take a close look at this later in this section.

This chapter looks at how we can use Scrum as an agile project management model to deliver software using TFS. We cover the scrum process a little deeper than in Chapter 3, adding how we in practice could use scrum and agile practices such as agile estimation and planning in combination with TFS.

This chapter does not cover eXtreme Programming (XP)—not because it is not useful, but because XP practices are covered in the more technical chapters later in this book. This chapter focuses purely on the project management features for scrum included in TFS 2012.

The Scrum Process

Figure 6-1 shows the Scrum process. The requirements from the business side of an organization are put on a backlog as Product Backlog Items (PBIs). The backlog itself is an ordered list with the (currently) most important requirements at the top. When the first sprint starts, the development team, together with the PO, selects a number of PBIs for the sprint backlog (SP) in the sprint planning meeting. The team commits to delivering these Sprint Backlog Items (SBIs) and starts working on them.

Product Owner

The product owner is the role that most equals traditional project managers (PM). The full truth is that the responsibilities of the PM have been divided between all three roles in scrum, but a good part has landed on the PO role. The focus right now in this chapter is on the PO role because the scrum master’s and development team’s responsibilities are covered all through the book. Much of what the PO is responsible for ends up in TFS—especially in the beginning of the project. Here are a few things the PO is responsible for:

• What to build and who should create the vision for the project. It is only the PO that decides what the project should build and deliver. The PO has final say in all decisions regarding the “what” question. This is not always the case because reality might get in the way, but things will be much harder if the PO does not have the authority to make all decisions.
• Project delivery. A PO can never say that the development team did not build what the PO wanted. If that situation occurs, the PO has done a bad job and probably not been as present and dedicated as he or she should have been.
• Requirements and estimation. When the need for a new system (as an example) comes up in the organization, the PO should be responsible for gathering initial requirements and estimating these. We look at this in more detail later in this chapter.
• Creating the initial backlog and keep on grooming it. Based on the requirements, the PO creates the initial backlog. During the project, the PO is responsible for keeping the backlog in good shape (also known as backlog grooming). Included here is the art of breaking down the backlog into manageable pieces, which is something the PO does with the help of the rest of the team.
• Prioritizing the backlog. For the team to build the right thing it is important that the backlog is ordered in some way. By prioritizing the product backlog, the team knows what tasks to take on first. It is the PO that is responsible for this prioritization. The PO can probably not do this by himself so the team is welcome to help and give input.
• Calculate the estimated budget and ROI. With initial requirements and estimation done, the PO can calculate the estimated budget and Return On Investment (ROI) of the project so that he or she can convince stakeholders that the project is necessary to carry out.
• Product management. The PO should know what and why we build something. All requirements and requests coming into the project should be filtered through the PO. After looking at the incoming requests, the PO decides what to place on the backlog. Nobody else decides that.
• Stakeholder management. The PO is of course not alone with all these responsibilities. The PO needs to manage all stakeholders and end user input so that he or she knows what the organization wants; otherwise it is hard to make the decisions. One way of doing this is to schedule repeated stakeholder meetings where the needs and priorities of the organization are discussed.
• Release management. It is important early on in a project to get an overview of the releases in the project. Do we have a specific theme that drives a release or a certain set of functions that should be a release? The PO should make sure this is done early on and then follow up this.
• Team manager/Staff project. The PO is responsible for staffing the project. Initially, the PO needs experienced people that can help with requirements and initial estimation. These people should then follow the project until it ends in the best of worlds. Once the project starts, the PO makes sure it is scaled up in the best possible way.

These are some of the PO responsibilities. We will soon see how much of these are mapped into TFS. First, let’s look at the other two roles.

Scrum Master

The responsibilities of the scrum master (SM) include:

• Protecting the team. The team should be able to work without being interrupted by anything. For example, the team should not be disturbed by managers asking them to spend time on other (non-project) related tasks. If that happens the SM needs to explain to the manager why the team (or team member) cannot do the things the manager asks for. This is essential for the team to deliver what they have committed to deliver.
• Resolving problems. If the team or a team member is blocked by an obstacle and cannot continue working on a user story it is the scrum master that needs to resolve the problem. The SM needs to clarify what the problem is, why the block happened, and how it can be solved.
• Making sure the team (including PO) understands and complies with the scrum process in the right way. It is also the scrum master that needs to make sure that the rest of the organization outside the scrum team understands the process and why it is important to stick to it.

The Development Team

So now we have come to the team, the ones producing the actual code. Here are some responsibilities of the development team:

• Deciding how to build what the PO has decided to build. The team is responsible for coming up with the solution, breaking down user stories, and giving feedback and suggestions to the PO and a lot more.
• Delivering quality code. This means that they need to comply with the requirements in the Definition of Done (DoD), which we will discuss later in this chapter.
• The estimates of user stories, both before and during a sprint. The team needs to estimate as the best they can to give input to the PO. They also need to have a good dialog with the PO so that they can point out alternative ways for the project. If they feel that the PO should make another decision, they are obliged to point out and argue for a better way.
• Following the principles of XP. This might not be in the Scrum guide, but we recommend this from our own experience.

Requirements

In agile projects we usually represent our requirements in something called user stories. These can be looked upon as fluffy requirements—a little bit like use cases actually. We write user stories like this:

• As a < type of user > I want < some functionality > so I may have < some business value>

One example could be:

• “As a manager I want my consultants to be able to send in expense reports through the Internet so that we can be more efficient in our expense report process.”

Figure 6-2 shows how Microsoft has implemented the user story into the work item type Product Backlog Item. The terminology is a little different from my previous description, but it works.

User stories capture requirements at a high level and will not be tangled up with detailed functions or implementation details. The details and nonfunctional requirements are instead captured as acceptance criteria for the user story. Based on these acceptance criteria, we can also develop acceptance tests at the same time we write the requirements.

The DoD is also important here because it describes other important requirements all user stories need to fulfill before they are done.

So, how can we go ahead with gathering requirements before we start a project? The PO should use any method he or she thinks is suitable. We often use story-writing workshops where important stakeholders, end users, business analysts, experienced developers, and others may participate to brainstorm the user stories they can think of. During such a workshop we focus on the big picture and do not dive down into details. These big user stories are often called epics because they are big and not broken down into details yet.

But don’t we need to find all requirements at the beginning? No. And that is what makes agile so great. The agile concept builds on the fact that we acknowledge that we don’t know and cannot know all the requirements early in the project. New requirements and changes to early requirements will pop up all through the process, and that is okay The agile approach takes care of this for us. We start with what we have initially and continue handling requirements all through the project. So the short version is to get started right a way and be aware that changes and new requirements will come.

When the initial requirements are done, we have the embryo for the product backlog. However, before we can prioritize and estimate these user stories we need to perform a risk assessment of them so that we can get a grip on any risk associated with each and every one of them. A user story with a great risk associated with it usually takes more effort to finish and should probably be done early in development.

Estimation

To know the effort involved with a user story we need to estimate it. The sum of all initial estimates gives us a (very) rough estimate of how much time the whole project might take. But because we know things usually change over time we do not take this estimate as if it was written in stone.

So, how do we do estimation? We have what we need to do this, we know the requirements, we have a DoD, and we have acceptance criteria.

In the agile world it is recommended to estimate time in something called story points. Story points are not an exact size—instead they are relative.

Here is an easy example we use when running agile training. Take four animals, for instance. Let’s say a cat, a pig, a zebra, and an elephant. Without being a zoologist, most persons can say that the pig is three times the size of the cat, the zebra is twice the size of a pig, and the elephant is maybe four times the size of the zebra. If we sit down a couple of people and discuss these animal sizes, we pretty soon can come up with an agreement on their relative sizes.

The same goes for user stories. Most developers will come up with an agreement pretty quickly about the relative size of user stories. User story A is twice as big as user story B, and so on. We do not need to be very experienced in the details of each user story to come up with this agreement. Novice developers usually end up with the same estimates as experienced. Keep in mind that we are not talking exact time yet, only relative size.

The most common scale for expressing story points is a modified Fibonacci scale. This scale follows the following sequence: 1, 2, 3, 5, 8, 13, 20, 40, and 100.

Very often teams use a technique called planning poker when doing estimates. The deck of cards each player has contains the numbers from the modified Fibonacci scale. Here is how it goes:

• PO/SM reads the first user story.
• The team briefly considers the user story and selects a card each, without showing it to the others.
• The team shows their cards at the same time.
• If the result varies much, the person with the highest and lowest card explain how they reasoned.
• After a short discussion the team plays again.
• When consensus is reached (or the team members are only one step from each other), you are done.
• If you still disagree, the team should pick the highest value.

But what about time then, someone asks. How can we get down to time? There are several things that we need to know to estimate time. The first is the team capacity. Consider the following when calculating the team capacity.

• How long is the sprint?
• How many working days are available in the sprint?
• How many days does each team member work during the sprint? Planned vacation or other days off, planned meetings, and so on.
• Deduct the time for Sprint Planning, Review och Retrospective meetings.
• The result of this is the capacity before “drag” (drag is waste time or unknown activities).
• We should measure drag in each sprint but at the initial planning we really don’t know how much we should calculate with. The longer the project, the more accurate the drag will be.
• If you don’t know from experience what the drag is, 25 percent can be a good landmark. Included in this is 10 percent backlog grooming.
• Now we have the available number of hours in the sprint.

We now should connect points and time. We need to know the team velocity, which is the number of story points the team can handle in a sprint. Initially this is impossible to know. The easiest way to figure it out is to perform a sprint planning meeting. This is the meeting where the team breaks down a user story into manageable tasks. And this is where time becomes interesting. During this meeting the team estimates the tasks in hours so that they can plan the sprint and decide on how many user stories they can take on in their sprint. This is usually the way team performs this:

• Estimate the first user story in detail.
• Break down what the team needs to do to deliver the story.
• Estimate hours for each activity and summarize.
• Deduct the summary from the available time the team has in the sprint.
• Is there still time left?
• Take a new user story and repeat the process until no available time is left.
• Summarize the number of story points from the stories that were included in the sprint.
• Now we have a theoretical velocity.

Now that we know the velocity of the team we can make a rough time plan for the entire (at that point known) project. This is good input for the PO in his or her discussions with stakeholders, and also input for ROI calculations.

The sprint planning process then continues all through the project and the theoretical velocity can soon be replaced with one based on experience instead. We will come back to this several times later in the book, starting in Chapter 8.

Backlog

When the initial user stories are in place and estimated with story points, the PO can start prioritizing the backlog. In scrum this is called ordering the backlog. Based on the business needs, the PO makes sure that the order of the backlog reflects what the business wants. In Figure 6-3 we can see the initial backlog we used for writing this book. We did a rough estimate on each backlog item and then a velocity planning. After that we could see what backlog items should be completed during which sprint (two-week sprints were used).

The PO needs to keep the backlog in good shape all through the project. This means that it needs to be ordered. It also needs to have fine granularity at the top (maybe 3–4 sprints down the list) and rougher granularity further down.

The PO can also start to look at release planning at this point. It is important to get an overview of coming releases in the project especially if you have a larger project. Release planning can be done on the epics, the larger user stories. A good way is to look for themes among the user stories. What could be useful to release at the same time? If we find such features, we could make a theme of it and plan the theme for a certain release.

When this is done we could also do a very rough time estimate on the releases and suddenly we also have a rough time plan for the project.

Now we have as much information as we could possibly ask for this early in a project. The next step will be the sprint planning meeting when the team (as we showed earlier) has a planning meeting and selects the backlog items they feel they can commit to during the sprint.