Getting to know product backlog, release planning, and iteration planning
Learning about the new product planning workbook
Learning how to use the product planning workbook for planning the release and iteration, as well as managing the product backlog
Learning about the new iteration planning workbook
Learning how to use it for managing the iteration
Understanding the issues and retrospectives spreadsheet
In Chapter 23, you learned about the process templates included in Visual Studio Team Foundation Server 2010. One of those templates is the Microsoft Solutions Framework (MSF) for Agile Software Development process template. For agile teams, planning is a day-to-day activity, and planning certainly helps the team to stay on track, as well as work toward getting the most important things done on time.
Team Foundation Server 2010 in its MSF for Agile Software Development v5.0 process template includes two new workbooks that are designed specifically to help agile teams with the planning activities. This chapter examines the product planning workbook and the iteration planning workbook. You will learn how these workbooks can be used to manage the product backlog, to plan out iterations and track them, to understand the team capacity and to watch the velocity of the team, which is important to plan future iterations.
It is a common myth that agile teams do less or no planning at all. To the contrary, agile teams require a lot of rigor and discipline when it comes to planning and tracking. It is critical to the success of agile teams that the entire team takes part in the planning process and that team members commit themselves to the plan. That is not to say that the plan is rigid, but rather that every member of the team has skin in the game.
In the book Planning Extreme Programming (Boston: Addison-Wesley Professional, 2000), authors Kent Beck and Martin Fowler say, "We plan to ensure that we are always doing the most important thing left to do, to coordinate effectively with other people, and to respond quickly to unexpected events."
Agile teams plan at two different levels — one at the macro level to understand the release schedule and the other at a more granular level to plan and manage each of the iterations.
This chapter delves into how you can use the planning workbooks to help with planning at both levels that are essential for agile teams.
For agile teams, the product backlog serves as the singular representative of the customer requirements in a prioritized (and stack-ranked) order. A product backlog contains a list of user stories as defined by the customer. Hence, it is very important that the team keeps the product backlog up to date. At the beginning of any project, the team will start by adding user stories to this backlog.
As part of the release-planning effort, the stories in the product backlog are prioritized and estimated. Note that the prioritization of the backlog also takes place on an ongoing basis. It is also common for new user stories to show up in the backlog during the course of the project. Typically, it is the responsibility of the product owner to manage the backlog and reprioritize the items in the backlog as appropriate.
By default, in Team Foundation Server, story points are used as a unit of measurement to assess the size of the user stories. Story points are based on a relative size, rather than an absolute value. The story point assessment is based on the perceived size and/or complexity of a user story, rather than the time of effort it would take to implement a user story.
Estimates for user stories typically use a non-durational value — for example, a t-shirt size or story point. It is important to note that the goal here is to not get to a level of precision (even if you try, it is really difficult to do this) but to have a relative measurement of each of the user stories. So, a story estimated as a large t-shirt size, or eight story points, should be bigger than a story estimated as a medium t-shirt size, or four story points.
It is helpful (and recommended) that you break down into smaller increments those user stories that are larger and difficult to estimate. These larger user stories sometimes are referred to as epics or novels. Teams tend to not spend a lot of time in estimating these larger user stories because it is likely that these will be analyzed and split into smaller user stories before this can be assigned to any iteration.
After a set of user stories in the product backlog have been prioritized and estimated, the teams can work to get a release plan in place. A release plan is primarily based on the minimal set of features that are required to be implemented for the system/application to have the expected impact. This set of features could be considered a minimally credible release. Once this is identified, then, based on the estimates (story points) and the expected (or known) velocity of the team, a release plan that includes a schedule can be derived.
For example, let's say that the total set of user stories to reach a minimal credible release is about 240 story points and the team's known or expected velocity is 30 story points per iteration. In this case, a team will take eight iterations, or about four months, to complete these user stories if the iterations are two weeks long.
Another way to get to a release plan is to use a time box. This approach has been effective when targeting a time window to get a project out. When using the time-box approach, a deadline is driven by something such as a marketing ad campaign, a legal requirement, a competitive launch, or some other factor that requires a release by a certain date. In this case, you work back from the release date and figure out how much of the customer requirements or user stories can be fulfilled in the time available, based on the velocity of the team. For example, if a release is required in four months, and the team's expected or measured velocity is about 30 story points per iteration, then a team running two-week iterations could commit to completing user stories totaling 240 story points.
Figure 25-1 shows a representation of a product backlog with a list of user stories and a cut-off line identifying the minimal credible release. The list of user stories above this cut-off line is worked on during one or more iterations. In this example, it takes three iterations to get the first release out.
Note that the customer requirements and the priorities of these requirements could change as the project progresses. It is important that the product backlog is kept up to date with any changes to the backlog in terms of priorities, new user stories to be added, or existing user stories that can removed.
In its MSF for Agile Software Development process template, Team Foundation Server 2010 includes a Microsoft Office Excel workbook to create and manage the product backlog.
To work with this workbook in Microsoft Office Excel, you should have the Team Foundation Server Office add-in installed.
After you create a new team project using the new MSF for Agile Software Development v5.0 template, you will find the planning workbooks (both the product and iteration backlog workbooks) under the My Agile Project
The product planning workbook gets the data from a work item query appropriately named Product Planning. This query is created during the team project creation and can be found under My Agile Project
Before delving into the details of the product planning workbook, let's take a quick look at the query itself. As you can see in Figure 25-3, this query pulls all work items of type User Story with any state other than closed, and user stories that were closed in the last 90 days.
This query brings a list of user stories that are open and that are recently closed. There is also a Product Backlog query that brings in only open user stories.
Now, let's look at how this query gets wired up to the product planning workbook. To do that, let us switch from Visual Studio to Microsoft Office Excel. From the Excel ribbon, select the Configure
Note
Check that team members have required permissions to modify the workbooks. Team members who would be making changes to the workbooks must be part of the "Contributors" group.
In the Configure List Properties window, you can see the query that this workbook is attached to.
That concludes this quick overview of the mechanics to get the planning workbook wired up with the corresponding query. With the basics out of the way, let's now focus on the following three worksheets in the product planning workbook:
Product backlog — You will use this worksheet to manage the product backlog, including work for various iterations, stack ranking work items, estimation of work items, and more.
Iterations — You will use this worksheet to maintain information about iterations, including the duration (start date and end date) and team size.
Interruptions — You will use this worksheet to manage interruptions to your schedule (such as holidays).
The product backlog worksheet displays a list of user stories, as shown in Figure 25-5. These are the results of the Product Planning query presented in this Excel spreadsheet.
Obviously, you can now use the familiar and powerful capabilities of Microsoft Office Excel to manage the list of user stories in the backlog. This worksheet shows the fields that you require to manage customer requirements using user stories, to prioritize them using stack ranks, to estimate them using story points, and to assign the user stories to iterations using the iteration path.
The list of user stories shown in Figure 25-5 is from a sample team project created to help explain the backlog workbooks. The workbook contains several user stories that are stack-ranked, with the higher-priority ones assigned to either Iteration 1 or 2. There are several user stories in the backlog that are not yet assigned to an iteration.
It is very common to not have all the user stories in the backlog assigned to an iteration. There could be multiple reasons for this. It could be because not all of the user stories in the backlog are going to be worked on by the team for the current release. Or, it could be that the team only wants to commit to work on two iterations at a time, knowing that there will be changes to the backlog as the project progresses, and planning out more than couple of iterations may not be that useful anyway.
The product backlog worksheet is primarily used to do the following:
Create new user stories
Prioritize user stories in the backlog
Estimate user stories
Assign user stories to iterations
Once you have a backlog worksheet, you can add new user stories, stack-rank user stories against the rest of the stories in the backlog, and provide story point estimates.
The changes you make to this worksheet can be published back to Team Foundation Server. Updated data can be pulled from Team Foundation Server to this worksheet using the Publish and Refresh menu items found in the Team tab of the Excel ribbon, as shown in Figure 25-6.
From within Microsoft Excel you can make bulk edits to the work items. The workbook as part of the publish process will validate the work item entries for any validation errors. Work items that have validation errors will be presented in a dialog, as shown in Figure 25-7, and you will have a chance to fix the errors and republish.
You could also perform all of these activities from within the Team Explorer as well. From within Team Explorer, run the product backlog query and the results will be the backlog, as shown in Figure 25-8.
It is worth emphasizing the importance of keeping the product backlog up to date throughout the course of the project. The updated product backlog will be used during the iteration planning meeting. You'll learn more about the iteration planning meeting later in this chapter.
The next worksheet in the product planning workbook is the iterations worksheet. (Do not confuse this with the iteration planning workbook, which will be explored later in this chapter.)
Mostly used by the product owner in the agile team, this worksheet is useful for keeping information about the iteration (such as the start date, end date of iterations, and team size). This worksheet displays a graph of planned and delivered work in each of the iterations, as shown in Figure 25-9. Obviously, the data is based on the status of the work item assigned to the various iterations, duration of the iterations, number of team members for each iteration, and also any interruptions in the schedule. The interruption information is captured in the next worksheet in the product planning workbook.
The third worksheet in the product backlog workbook is the interruptions worksheet. You use this worksheet to enter time during the iteration that the team member won't be available to work on the project (such as holidays, team off-site meetings, team training, and so on). These days would not be factored in to the total iteration days available in the iteration planning worksheet. Figure 25-10 shows a sample of an interruptions worksheet with holidays and a team offsite meeting marked as days that the team won't be available to work on the project.
As you know, agile teams do their planning on two levels. Release planning provides a long-term view (usually 6 to 12 months) of the project, and the estimation of the release planning is usually done using a measure like story points. Iteration planning (or sprint planning) is more focused on a near-term view (2 to 4 weeks) of the project.
During the iteration planning stage, teams break down user stories into smaller user stories, and identify tasks required to complete each of the user stories. During the release planning, the order and dependencies between user stories are either mostly not known, or, if known, those were not given much attention. But, during the iteration planning, the team knows more about the user stories, as well as any and all dependencies that will impact the order in which the user stories can be worked on during that iteration.
An iteration planning meeting takes place before each iteration starts. During this meeting, the team commits to completing a set of user stories for that iteration. Note that the initial set of user stories identified for a particular iteration during the release planning may change. In addition to the user stories in the backlog, teams would also include bugs, spikes, and any technical debt that must addressed.
Spikes are essentially a time-boxed effort used by teams to explore solutions to tackle a user story, or to make a design decision. Spikes are necessary when further technical exploration is necessary to come up with a plausible solution. Note that spikes are not science projects. So, it is critical that the spikes are time-boxed. The results of the spike effort are reviewed immediately for any impact to the current iteration plan, and, of course, this is factored into the subsequent iteration planning.
The team spends most of its time during the iteration planning meeting identifying tasks and estimating them. Teams use many techniques and tools to aid them in estimation. A good book to serve as a reference for such tools and techniques is Agile Estimation and Planning (Upper Saddle River, NJ: Pearson Education, 2006) by Mike Cohn.
Note
Teams play a game called "planning poker" to help with estimation. This game is very helpful, especially for newly formed teams, and for teams that are just getting started in using agile practices. For more information, check out: http://www.planningpoker.com/.
At the end of an iteration planning meeting, the teams have a clear understanding of the work that they have committed to perform.
In its MSF for Agile Software Development process template, Team Foundation Server 2010 also includes a Microsoft Office Excel workbook called the iteration backlog workbook for creating and managing the iteration backlog, which is a workbook similar to the one used for managing product backlogs.
As part of the setting up the team project, Team Foundation Server creates three iteration backlog workbooks. These will be found under My Agile Project
For further iterations, you want to copy the iteration backlog workbook from either the Iteration 1 folder, or the template provided in the Sample and Templates folder. Once you copy the workbook, configure the workbook with the corresponding iterations backlog query.
As with the product backlog, the iteration backlog is wired up by its own queries. Figure 25-12 shows the iteration backlog query in the query editor.
As you saw in Chapter 22, Team Foundation Server 2010 now supports hierarchical work items. You can now have queries to pull work items in a tree list that will show the linked work items. Iteration backlog uses a query to pull one such tree list. By default, the iteration backlog query retrieves user stories and tasks, as well as any linked task work items.
Note that during the iteration planning meeting, the bugs are prioritized along with the user stories and features. If the bugs get prioritized higher than certain user stories or tasks, then the team works on the bugs.
The iteration backlog workbook contains the following five worksheets:
Iteration backlog — Use this worksheet to manage work items in that iteration.
Settings — Use this worksheet to specify the iteration start date and end date. Note that these dates are not stored in Team Foundation Server.
Interruptions — Use this worksheet to specify any time taken off by the team members during the iteration (such as vacations, training, and so on). You can also specify any interruptions that are team-wide (such as holidays, team-wide meetings, and so on). The interruptions are used when calculating the team capacity for the iteration, as well as individual capacity.
Capacity — This worksheet shows the capacity of the team and individuals for the iteration.
Burn-down — This worksheet has a chart that shows the trend lines for completed hours, remaining hours, and the ideal trend.
Now, let's take a closer look at the iteration backlog worksheet and the capacity worksheet.
Figure 25-13 shows the Team tab in the Excel ribbon. Obviously, you see the familiar Publish, Refresh, and Configure menu options in this tab. However, the menu options that get a lot of use while managing the iteration backlog are Outdent, Indent, and Add Child.
The Outdent and Indent menu options are self-explanatory, and, as the names suggest, will move up or down the levels of a work item. Note that the links of work items will change based on the level at which the work item ends up after either an Outdent or Indent action.
Similarly, as the name suggests, the Add Child menu option adds a linked child work item to the work item that you have selected. Note that the child work item gets added to the row that is currently selected when clicking the Add Child option. In Figure 25-14, you can see that seven child work items have been added to the user story work item titled "As a user I want to login to the Website so I can order things."
Note
When you add child items in Excel as shown in Figure 25-14, the child work items are not automatically assigned to the same iteration the parent work item is in. You must manually choose the iteration in the Iteration Path column. It is a little annoying, but the Excel bulk edit sure helps. Note that if you add child work items in Team Explorer, the iteration path is automatically set to the iteration of the parent work item. So, this is only an issue in Excel workbooks.
Iteration worksheets also have several validations built in. When you add child work items and publish the changes to Team Foundation Server, the validation logic runs and looks for any errors. For example, if you did not specify the type of work items for the child work items created, you will see an error and be prompted for those to be fixed before the changes are published to Team Foundation Server.
So, once you have created sub-user stories and tasks, you can do the estimation during the iteration planning meeting.
When it comes to work assignments, you basically have two choices:
Some teams assign the chosen tasks (and bugs) to the individual team members for the iteration.
Other teams identify the work that the team commits to and allow the team members to pick the work during the iteration.
Note
It is common practice not to assign tasks for the entire iteration, but rather identify certain areas where a particular team member has expertise, or has worked on something relatively similar, so you can factor that in to the planning process. However, if you do assign tasks to an individual team member, be aware that these assignments are subject to change during the course of the iteration.
One of the key activities during the iteration planning is the estimation of tasks. The user stories assigned to the iteration from the product backlog have story points. As you learned earlier in this chapter, story points are not a measure of time or actual effort. So, the team spends time estimating the tasks during the iteration planning meeting. You enter the estimations in the Remaining Work column of this worksheet. Once the team finishes the exercise, the backlog worksheet should look similar to Figure 25-15.
As the work gets completed during the iteration, the team members will update the Remaining Work and Completed Work entries for each of the tasks. These will be used in many reports, including a burn-down chart.
It is worth emphasizing that, after the team goes through estimating tasks and, hence, committing to work, it is likely that not all user stories originally assigned for this iteration will be included or committed to in that same iteration.
Once you make these changes (that is, sub-user stories, tasks, estimates, team assignments, if you choose to do so), you save the changes back to Team Foundation Server by using the Publish option in the Excel workbook. Once you publish this workbook, the planning is complete, and the team is set to begin the iteration.
In the capacity planning worksheet, you can specify the availability of team members during the iteration, as well as how many hours each day the team members are available to work on the iteration. This worksheet provides a visual representation of the team capacity as a whole, as well as the workload for the individual team members.
The two sections in this worksheet are for the team capacity and individual team member capacity. Let's look at each of these.
This worksheet section provides a summary view of the remaining work, team capacity, hours utilized, and whether the remaining work is over or under the capacity.
As you can see in Figure 25-16, this data is also represented in a chart on the top right that provides a color-coded view of the team capacity and the status of allocation. In the example shown, the team's capacity is 162 hours, and the total remaining work for this iteration is 178 hours. That leaves the team with 16 more hours of work than capacity, which is indicated by a red bar at the end of the chart.
In the Individual Capacity table in the middle of the Figure 25-16, you see a list of team members with their availability, hours per day, how much work they are assigned to, and what their load looks like.
There is also a chart that shows how the load is distributed among the team members. Anything appearing in red in this chart means a team member is over-allocated, which is never a good sign. In the example shown in Figure 25-16, two members are overloaded (Joe Smith and John Doe).
After looking at the example capacity planning worksheet, there are obviously two issues that must be resolved as a team:
There is more work planned for than the capacity in this iteration.
There are team members who are overloaded.
To solve the first issue, the team must get the lowest-priority user story out of this iteration so that the workload can be brought under the capacity. To solve the second issue, work must be reassigned among the team members to get the load balanced.
During the iteration, it is important that the team watches the progress being made against the plan. It is not uncommon for tasks to take longer or shorter than the estimate derived during the iteration planning meeting. Watching the burn-down chart would give a good sense of the team's progress. It is critical that team members update the Remaining Work and Completed Work entries in the worksheet on a frequent basis. Team members can do this by using the work item form from within Visual Studio, by using a browser with the Web access or by using the Excel backlog.
Dashboards are very handy to get the information you need, regarding the status of the iteration. As you saw in Chapter 24, Team Foundation Server 2010 includes a Project Dashboard that includes the burn-down chart, burn rate of the team (both actual and required), and the backlog, all in one view.
Stand-up meetings are a great way to get a handle on roadblocks or issues that are being faced by the team that might be impeding the progress. These daily meetings are not the place to analyze and solve the issues, but rather just bring the issues to the surface.
Team Foundation Server 2010 includes an issues spreadsheet that can be used to capture and track the issues being identified in the stand-up meetings, or at any time during the project. It is easy to capture them in a spreadsheet and, given that this spreadsheet is wired to Team Foundation Server, issues that are identified can be published to Team Foundation Server and tracked on a regular basis.
Agile teams run retrospectives at the end of every iteration to reflect on the iteration that they just completed. The key areas discussed during the retrospectives enable the team to understand the things that went well, the things that did not go well, and the things that the team can improve during subsequent iterations.
Under My Agile Project
In this chapter, you learned about the backlogs included in the MSF for Agile Software Development v5.0 template in Team Foundation Server 2010. You learned how the product backlog works, and how to use this backlog as part of the release planning process.
You also learned about iteration planning and how it is different from release planning. You learned how to use the iteration backlog workbook and how it can help an agile team manage iterations and track the project progress.
You learned how the load-balancing worksheet can be used to manage the workload of the team members, as well as to manage the work planned for iteration against the team capacity.
Lastly, you learned about how the issues worksheet can help in tracking issues identified during the project and during daily stand-up meetings. You also learned about the templates available for capturing information gleaned from retrospectives.
Chapter 26 covers the process customization and the tools available to customize process templates to meet the needs of a project team. Customization also takes place on an ongoing basis, based on learning during the execution of the project. Chapter 26 examines the process template editor and how you can use it to customize the process template of your choice.