This chapter is from the book
This chapter is from the book
This chapter is from the book
Process Cycles and TFS
A core concept of the convergent evolution discussed in Chapter 1 is iterative and incremental development. Scrum stresses the basis of iteration in empirical process control, because through rapid iteration the team reduces uncertainty, learns by doing, inspects and adapts based on its progress, and improves as it goes.5 Accordingly, Scrum provides the most common representation of the main macro cycles in a software project: the release and the sprint (a synonym for iteration), as shown in Figure 2-3. Scrum provides some simple rules for managing these.
)
Figure 2-3 Software projects proceed on many interlocking cycles, ranging from the "code-edit-test-debug-check in" cycle, measured in minutes, to continuous integration, to daily testing cycles, to the sprint. These are views of both the process and the flow of data, automated by the process tooling.
Release
The release is the path from vision to delivered software. As Ken Schwaber and Jeff Sutherland explain in the Scrum Guide:
- Release planning answers the questions, "How can we turn the vision into a winning product in best possible way? How can we meet or exceed the desired customer satisfaction and Return on Investment?" The release plan establishes the goal of the release, the highest priority Product Backlog, the major risks, and the overall features and functionality that the release will contain. It also establishes a probable delivery date and cost that should hold if nothing changes.6
The release definition is contained in the product backlog, which consists of requirements, unsurprisingly named product backlog items, as shown in Figure 2-4. Throughout the release, the Product Owner keeps the PBIs stack ranked to remove ambiguity about what to do next. As DeMarco and Lister have put it:
- Rank-ordering for all functions and features is the cure for two ugly project maladies: The first is the assumption that all parts of the product are equally important. This fiction is preserved on many projects because it assures that no one has to confront the stakeholders who have added their favorite bells and whistles as a price for their cooperation. The same fiction facilitates the second malady, piling on, in which features are added with the intention of overloading the project and making it fail, a favorite tactic of those who oppose the project in the first place but find it convenient to present themselves as enthusiastic project champions rather than as project adversaries.7
)
Figure 2-4 A product backlog item, shown here as accessed inside the VS IDE, can also be viewed from the Web Portal, Microsoft Excel, Microsoft Project, and many third-party plug-in tools available for TFS.
A common and useful practice is stating the PBIs, especially the functional requirements, as user stories. User stories take the form As a <target customer persona>, I can <achieve result> in order to <realize value>. Chapter 3, "Product Ownership," goes into more detail about user stories and other forms of requirements.
Sprint
In a Scrum project, every sprint has the same duration, typically two to four weeks. Prior to the sprint, the team helps the Product Owner groom the product backlog, estimating a rough order of magnitude for the top PBIs. This estimation has to include all costs associated with completing the PBI according to the team's agreed definition of done. The rough estimation method most widely favored these days is Planning Poker, adapted by Mike Cohn as a simple, fast application of what had been described by Barry Boehm as the Wideband Delphi Method.8 Planning Poker is easy and fast, making it possible with minimal effort to provide estimates that are generally as good as those derived from much longer analysis. Estimates from Planning Poker get entered as story points in the PBI work item. Planning Poker is discussed further in Chapter 4, "Running the Sprint."
Another great practice is to define at least one acceptance test for each PBI. These are captured in TFS as test cases, a standard work item type. Defining acceptance tests early has three benefits:
- They clarify the intent of the PBI.
- They provide a done criterion for PBI completion.
- They help inform the estimate of PBI size.
At the beginning of the sprint, the team commits to delivering a potentially shippable increment of software realizing some of the top-ranked product backlogs. The commitment factors the cumulative estimate of the PBIs, the team's capacity, and the need to deliver customer value in the potentially shippable increment. Then, only the PBIs committed for the current sprint are broken down by the team into tasks. These tasks are collectively called the sprint backlog (see Figure 2-5).
)
Figure 2-5 The sprint backlog, shown here as accessed from the Web Portal, consists of the tasks for the current sprint, derived from the PBIs to which the team has committed.
Don't Confuse Product Backlog and Sprint Backlog
In my experience, the most common confusion around Scrum terminology is the use of the word backlog in two different instances. To some extent, the confusion is a holdover from earlier project management techniques. The product backlog holds only requirements and bugs deferred to future sprints, and is the interface between the Product Owner, representing customers and other stakeholders, and the team. PBIs are assessed in story points only.
The sprint backlog consists of implementation tasks, test cases, bugs of the current sprint, and impediments, and is for the implementation team. When working on a task, a team member updates the remaining hours on these tasks, but typically does not touch the PBI, except to mark it as ready for test or completed. Stakeholders should not be concerned with the sprint backlog, only with the PBIs.
Handling Bugs
Bugs should be managed according to context. Different teams view bugs differently. Product teams tend to think of anything that detracts from customer value as a bug, whereas contractors stick to a much tighter definition.
In either case, do not consider a PBI done if there are outstanding bugs, because doing so would create technical debt. Accordingly, treat bugs that are found in PBIs of the current sprint as simply undone work and manage them in the current iteration backlog.
In addition, you often discover bugs unrelated to the current PBIs, and these can be added to the product backlog, unless you have spare capacity in the current sprint. (The committed work of the sprint should normally take precedence, unless the bug found is an impediment to achieving the sprint goal.) This can create a small nuisance for grooming the product backlog, in that individual bugs are usually too fine-grained and numerous to be stack ranked against the heftier PBIs. In such a case, create a PBI as a container or allotment for a selection of the bugs, make it a "parent" of them in TFS, and rank the container PBI against its peers (see Figure 2-6).
)
Figure 2-6 The product backlog contains the PBIs that express requirements and the bugs that are not handled in the current sprint. This can be accessed from any of the TFS clients; here it is shown in the VS IDE.
Avoiding Analysis Paralysis
A great discipline of Scrum is the strict timeboxing of the sprint planning meeting, used for commitment of the product backlog (the "what") and for initial task breakdown of the sprint backlog (the "how"). For a one-month sprint, the sprint planning meeting is limited to a day before work begins on the sprint. For shorter sprints, the meeting should take a proportionally shorter length of time.
Note that this does not mean that all tasks are known on the first day of the sprint. On the contrary, tasks may be added to the sprint backlog whenever necessary. Rather, timeboxing sprint planning means that the team needs to understand the committed PBIs well enough to start work. In this way, only 5% of the sprint time is consumed by planning before work begins. (Another 5% of the calendar, the last day of a monthly sprint, is devoted to review and retrospective.) In this way, 90% of the sprint is devoted to working through the sprint backlog.
Bottom-Up Cycles
In addition to the two macro cycles of release and sprint, TFS uses the two finer-grained cycles of check-in and test to collect data and trigger automation. In this way, with no overhead for the users, TFS can provide mechanisms to support both automating definitions of done and transparently collecting project metrics.
Personal Development Preparation
As discussed in Chapter 6, "Development," VS provides continuous feedback to the developer to practice test-driven development, correct syntax suggestions with IntelliSense, and check for errors with local builds, tests, and check-in policy reviews. These are private activities, in the sense that VS makes no attempt to persist any data from these activities before the developer decides to check in.
Check-In
The finest-grained coding cycle at which TFS collects data and applies workflow is the check-in (that is, any delivery of code by the developer from a private workspace to a shared branch). This cycle provides the first opportunity to measure done on working code. The most common Agile practice for the check-in cycle is continuous integration, in which every check-in triggers a team build from a TFS build definition. The team build gets the latest versions of all checked-in source from all contributors, provisions a build server, and runs the defined build workflow, including any code analysis, lab deployment, or build verification tests that have been defined in the build. (See Chapter 7, "Build and Lab," for more information.)
Continuous integration is a great practice, if build breaks are rare. In that case, it is a great way to keep a clean, running drop of the code at all times. The larger the project, however, the more frequent build breaks can become. For example, imagine a source base with 100 contributors. Suppose that they are all extraordinary developers, who make an average of only one build break per three months. With continuous integration, their build would be broken every day.
To avoid the frequent broken builds, TFS offers a form of continuous integration called gated check-in. Gated check-in extends the continuous integration workflow, in that it provisions a server and runs the team build before check-in. Only if the full build passes, then the server accepts the code as checked in. Otherwise, the check-in is returned to the developer as a shelveset with a warning detailing the errors. Chapter 9, "Lessons Learned at Microsoft Developer Division," describes how we use this at Microsoft.
In addition, prior to the server mechanisms of continuous integration or gated check-in, TFS runs check-in policies. These are the earliest and fastest automated warnings for the developer. They can validate whether unit tests and code analysis have been run locally, work items associated, check-in notes completed, and other "doneness" criteria met before the code goes to the server for either continuous integration or gated check-in.
Test Cycle
Completed PBIs need to be tested, as do bug fixes. Typically, team members check in code in small increments many times before completing a PBI. However, when a PBI is completed, a test cycle may start. In addition, many PBIs and bug fixes are often completed in rapid succession, and these can be combined into a single test cycle. Accordingly, a simple way to handle test cycles is to make them daily.
TFS allows for multiple team build definitions, and a good practice is to have a daily build in addition to the continuous integration or gated check-in build. When you do this, every daily "build details" page shows the increment in functionality delivered since the previous daily build, as shown in Figure 2-7.
)
Figure 2-7 Every build has a "build details" page that serves as an automated release note, accessible from the dashboard or inside the IDE clients. In this case, it is shown inside Eclipse, as a team working with Java code would see.
In addition, Microsoft Test Manager (MTM, part of the VS product line) enables you to compare the current build against the last one tested to see the most important tests to run based on both backlog changes and new or churned code, as shown in Figure 2-8. (See Chapter 8, "Test," for more information.)
)
Figure 2-8 This build assignment in Microsoft Test Manager is a great way to start the test cycle because it shows the new work delivered since the last tested build and can recommend tests accordingly.
Daily Cycle
The Scrum process specifies a daily scrum, often called a "daily stand-up meeting," to inspect progress and adapt to the situation. Daily scrums should last no more than 15 minutes. As the Scrum Guide explains, during the meeting, each team member explains the following:
- What has the team member accomplished since the last meeting?
- What will the team member accomplish before the next meeting?
- What obstacles currently impede the team member?
Daily scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve everyone's level of project knowledge.
Although TFS does not require daily builds, and the process rules do not mandate combining the daily and testing cycles, treating the daily cycle and test cycle as the same is certainly convenient. TFS helps considerably with preparation for the Scrum questions:
- As Figures 2-7 and 2-8 show, the automated release note of the "build details" page and the test recommendations of MTM help resolve any discrepancies in assumptions for question 1.
- The My Active Items query should align with question 2.
- The Open Impediments or Open Issues query, shown in Figure 2-9, should match question 3.
Figure 2-9 The Open Impediments query shows the current state of blocking issues as of the daily scrum.
)
These tools don't replace the daily scrum, but they remove any dispute about the data of record. In this way, the team members can focus the meeting to on crucial interpersonal communication rather than questions about whose data to trust.
Definition of Done at Every Cycle
For each of these cycles—check-in, test, release, and sprint—the team should have a common definition of done and treat it as a social contract. The entire team should be able to see the status of done transparently at all times. Without this social contract, it is impossible to assess technical debt, and accordingly, impossible to ship increments of software predictably.
With Scrum and TFS working together, every cycle has a done mechanism. Check-in has its policies and the build workflows, test has the test plans for the cycle, and sprint and release have work items to capture their done lists.