Determining the Hours Available in an Iteration

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Referenced Screen

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

  • Bringing Estimates and Capacity Together to Complete the Plan
  • Making Status Visible
  • Key Points
  • Copyright

The first step in determining iteration capacity is looking at how many hours are available in an iteration. Advanced teams will measure hours available for the whole team. Teams new to Agile will measure hours available by specialization. When you first move to Agile, you probably won’t have interchangeable team members; instead, you’ll have people with development skills, analyst skills, HTML skills, database skills, and other specializations. Over time, the team should cross-train and lose dependency on specific people for specific tasks; but on day one, specialization will probably be a reality, and you must plan capacity around that reality.

Acme Media knows that the team has 10 working days within their iteration. They use this information to determine how much capacity each team member has available (see Figure 16.7).

Figure 16.7 Acme Media determines its capacity for iteration 1. The spreadsheet takes implementation support into account and includes notes about other events that may affect the capacity of specific individuals.

Referenced Screen

Once the team understands their capacity, they begin loading up the iteration with features and tasks (see Table 16.2).

Table 16.2 As features are added to an iteration, the team can see the impact by functional area.

Est. Req.

Est. Ux

Est. Dev.

Est. Impl.

Est. QA

Est. Arch.

Sum

Ability to bid on an item

24

40

40

16

24

4

148

Ability to place an item up for bid

16

24

40

8

24

4

116

Ability to search by category

40

24

16

8

32

16

136

As Acme Media adds features, Wendy, the project manager, use a spreadsheet that calculates the difference between iteration assignments and team capacity. The team can see the workload by area and adjust the iteration features to keep everyone at approximately 100 percent usage (see Figure 16.8).

Figure 16.8 - The team can compare capacity to estimates as they add features into the iteration. In this example, the features assigned to the iteration are almost perfect for the developers, pushing them to 98% of their capacity. But the user experience group is booked way beyond their capacity at 207%. The team can back out features to get everyone closer to 100%, or they can disregard the calculation and choose to go forward if they feel comfortable doing so.

Referenced Screen

After the team reaches agreement on the features, they can commit to the iteration plan. Let’s look at some of the ways the iteration plan can be recorded.

Bringing Estimates and Capacity Together to Complete the Plan

When your team reaches agreement on the features for the iteration, you can use a multitude of tools to share the iteration information. In the simplest form, you can place all the tasks on a wall with index cards and let the team move cards over from the task backlog to the completed backlog.

Some teams use a combination of cards and online tools. The Acme Media team loads the iteration plan into a tool called a burn down chart that lets them view the iteration plan and present it to stakeholders and other parties who may not be on-site or have easy access to the team work area (see Figure 16.9).

You may also find that your iteration becomes complex due to dependencies and that it’s hard to keep track of all the work using an iteration wall or a burn down chart alone. In those instances, you can use tools such as Microsoft Project.

Some people believe that if you’re using a tool like Microsoft Project, you aren’t Agile. Many people believe that tools like Project imply formality and overhead, and they’re good only for traditional projects. We can tell you that this definitely isn’t true. It isn’t the tool that takes away agility but the way the tool is used. Let’s look at an example.

As we’ve mentioned, Greg is a project manager, and his team releases new software every 8 weeks. Greg typically uses tools such as an iteration wall and burn down charts. But his team noted that on some iterations, it was hard to keep track of dependencies. Greg’s team asked if he could record the dependencies into a plan so the team could track them during the iteration. Greg moved the iteration plan into Microsoft Project, and the team found the tool valuable, especially because they still had a level of specialization. Microsoft Project not only helped the team deal with complexity but also showed the team estimated hours needed by each member during the iteration.

Figure 16.9 Acme Media enters its iteration plan into a burndown chart that lets them track the work remaining as the iteration progresses. An electronic tool makes it easier to share status with the rest of the company or the customer.

Referenced Screen

Returning to Acme Media, project manager Wendy debates whether to enter the iteration information into a tool such as Project. Wendy decides that little labor is required to enter the information into the tool; plus, her team is familiar with it. You can see Acme Media’s iteration plan in Project in Figure 16.10.

Now that the Acme team has their iteration plan, they’re ready to get started with their feature work.

Making Status Visible

Historically, there are two issues with measuring status on software projects:

  • How do you make sure the code is complete?

  • How do you make it easy for the team to see and understand project status?

Project teams have struggled with these issues for years. They frequently prepare to deploy code and at the last second realize something is missing.

Let’s delve into these two issues and see how Acme Media simplifies status measurement and makes status transparent to the team.

Figure 16.10 Microsoft Project isn’t usually viewed as a tool used by Agile teams, but it can help with agility when an iteration becomes complex or team members need to anticipate how much work they must deliver. The key to using a tool is to make sure everyone knows that assignments are tentative and to ensure that the plan is highly visible and updated daily.

Referenced Screen

Visibility within an Iteration

As we mentioned, Acme Media has entered its iteration tasks into a burn down chart, which projects how much work should be completed as the iteration progresses. On a day-by-day basis, the team can see if they’re on track, running behind, or running ahead of schedule (see Figure 16.11).

Acme Media estimates 152 hours of tasks to complete for the iteration. The burn down chart shows that this number needs to be down to 138 hours of work after day 1, 120 hours of work after day 2, and so on. On the last day, the team should have no hours of work remaining.

Software development doesn’t care if it’s being tracked in a nice linear chart. In reality, the work comes in surges, with the team sometimes stuck on an issue or problem and not making any progress. Figure 16.12 shows Acme Media’s burn down chart after 7 days of work.

Many teams collect the estimates for remaining hours of work at their daily stand-up meetings. This is where the days remaining line comes from in the chart. Day 1 represents the task estimates before work has begun, and day 2 represents the estimates after the first stand-up meeting. The Acme Media team has started work, and now they believe the work is larger than originally estimated. What was originally estimated at 152 hours of work is now estimated to be 160 hours of work.

This is a common occurrence: after your team gets deep into the code, they may encounter surprises and need to increase their estimates for hours of work remaining for some tasks. They will also discover new tasks that you’ll need to record into your burn down chart. The positive here is that some tasks will also be easier than expected, which will help your team stay on track toward completing the work within the iteration. Your team will also appreciate knowing the status of the iteration on a daily basis.

Figure 16.11 A burndown chart tells you how many hours of work you should have remaining as the iteration progresses.

Referenced Screen

Figure 16.12 As the iteration progresses Acme Media sees status on a daily basis. In this example they’re running behind after seven days of work, but they’re trending to get back on schedule.

Referenced Screen

This is a common occurrence: after your team gets deep into the code, they may encounter surprises and need to increase their estimates for hours of work remaining for some tasks. They will also discover new tasks that you’ll need to record into your burn down chart. The positive here is that some tasks will also be easier than expected, which will help your team stay on track toward completing the work within the iteration. Your team will also appreciate knowing the status of the iteration on a daily basis.

Acme’s situation also illustrates another common occurrence: as the team progresses from day 4 to 5, the amount of work remaining doesn’t change. This happens when a team gets stuck on an issue. The team may be investigating options or doing technical research, so no code is created during this time.

Tracking Release Status

As your team tracks status for the iteration, a person such as a project manager or ScrumMaster may be keeping track of the overall release. Let’s look at how Acme Media keeps track of release status.

Historically, Wendy the project manager used Microsoft Project to track release status, but team members frequently didn’t reference the tool because they found the plan hard to decipher or didn’t have Project installed on their PCs.

Wendy decides to go with a lighter tool for her team: a tool that will be easy to decipher and one that everyone can access. She creates the tool using Microsoft Excel, which makes it easy to post on the project wiki site and also easy to print. She calls the new tool the Progress Matrix (see Figure 16.13).

Figure 16.13 The Progress Matrix makes status easy for the whole team to comprehend quickly. Feature status is viewed from a binary status versus percentage complete.

Referenced Screen

The Progress Matrix allows Acme’s team to quickly digest status. The columns in the matrix convey completeness at each stage. The fields Wendy has decided to track are as follows:

  • Functional requirements. If the team feels they understand the initial scope of the feature, they mark this field as complete. The customer can still request changes later in the cycle.

  • Code written. The code is complete from the developer’s perspective.

  • Unit tested. The developer has executed the code locally, and it has passed the unit tests.

  • System integration. The code has been integrated into the system test environment and didn’t break other features in the existing code base.

  • Functional testing. If a feature passed integration testing, Acme has built the feature into the User Acceptance environment, and a tester has performed functional testing.

  • Customer approval. Acme’s customers review and test features during the adapt week. This box is selected when the customer approves the feature.

  • Load test. Acme’s development team load-tests features to make sure there is no unforeseen effect on performance.

  • DR code release. Acme Media has created a Disaster Recovery (DR) environment in case the Production environment ever goes down. The first step in a production code deployment is to put the new code into the DR environment.

  • Production code release. This indicates that a feature has been deployed to the Production environment. In theory, the project is over at this time; but Acme sometimes deploys code to the Production environment in advance of exposing it to users. This lets the team verify that the code works correctly in the Production environment.

We personally enjoy using tools like the Progress Matrix. They give management and the team quick insight into release status. When we introduce the matrix to teams and project managers, they frequently ask us if this is the only tool we use for release status. Our answer is, “it depends.”

Finding Tools that Work for You

Similar to the Agile team, the Agile project manager looks at the project and determines the best tools for tracking a project. If you’re tracking a project, the Progress Matrix is the lightest tool you can use. The project needs to be straightforward and mainly focused on development.

If the project becomes more complex, you can pursue a supplemental tool to help track all tasks, not just those tied to development. We have a friend who was the project manager on a medium-complexity project a few years ago. She wasn’t comfortable relying on the Progress Matrix or the iteration plan alone; she wanted another tool to make her more comfortable with tracking the project. Our friend disliked Microsoft Project and decided to track the project with an Excel spreadsheet (see Figure 16.14).

Figure 16.14 You can use tools such as Microsoft Excel to track project status. Tracking tools need to be easy to use and simple for your team to digest.

Referenced Screen

Note

So Many Tools, So Little Time

Numerous off-the-shelf tools are available for tracking the status of Agile projects. We’ve used many of the tools provided by Rally Software, VersionOne, and Thoughtworks. As you’ve seen in our case study, there are other tools, such as SharePoint, that weren’t made specifically for Agile work but that can be configured to support tracking features, iterations, and releases. Many tools also require no hardware on your side: you can use the tools on the vendors’ servers.

You can use various tools to track project status. The key is to pick a tool that makes it easy to display status to the team and to those who need to manage the project. We like the simple spreadsheet our friend created. It made it easy for her to track status on multiple tasks and still use the Progress Matrix to verify code completeness.

But what if a project runs for many months and has a multitude of dependencies and complexities? What tools should you use to measure such a large, complex project? It happens that Greg recently participated in such a project.

The project Greg worked on was slated to run 18 months. His company upgraded its intranet platform and migrated content for more than 40,000 system users. The team had been together many years and had adopted many Agile techniques and processes. These Agile processes were used to deliver a new release to the platform every 7.5 weeks. For the most part, Greg’s team leveraged the existing infrastructure and provided new features and enhancements with each release.

The team started the 18-month project using the same techniques they had used for the enhancement releases. They broke the 18-month project into releases and set out to do the work. During those 18 months, Greg’s team encountered many issues with applying release techniques to a large project, including these:

  • Many features took longer than a release to complete, such as procuring and installing hardware.

  • Features sometimes had as many as 10 dependencies that needed to be completed before work could begin.

  • The large project include 20 to 30 mini-projects. A given release could have as many as 1,000 tasks to be completed.

  • A good portion of the project was dependent on a third-party software provider.

The team could submit bugs to the vendor, but they couldn’t control when the bugs were fixed. Many times, the fix spanned several releases.

The complexity of this project pushed Greg’s team to keep track of tasks and features. They soon found that they needed three tools to keep track of issues, feature status, and the project at large. The team continued to use a Progress Matrix to track feature completeness, but they supplemented it with a list of outstanding vendor issues and a Microsoft Project plan. This plan provided a roadmap for the project and made it easier to see the dependencies associated with a feature or piece of work (see Figure 16.15).

In essence, Greg’s team created the correct level of agility for their project. They still delivered iteratively, received frequent customer feedback, and quickly adapted to change.

Figure 16.15 Complex projects frequently require the use of tools such as Microsoft Project to track timelines and dependencies. Using such a tool isn’t anti-Agile. Agile is all about using the correct level of documentation and process. In a complex project, a tool such as Microsoft Project provides the correct level of support.

Referenced Screen

Key Points

The key points from this chapter are as follows:

  • Acceptance tests are defined at the start of iteration planning to make it clear to the team what complete means.

  • Feature modeling is an effective practice for identifying the tasks needed to support a feature.

  • After tasks are identified, iteration planning becomes similar to traditional planning. Capacity is estimated and compared to detailed task estimates.

  • The project team can use tools to determine their capacity, but ultimately the team makes the call about the amount of work they can deliver during an iteration.

  • Many teams are initially constrained by skill sets and capacity planning and have to take available skills into account.

  • Many Agile teams list their iteration tasks on a wall so they’re easy to view and move during an iteration. Teams can use additional tools such as burn down charts, Microsoft Project, and project wikis if iterations become complex or if the information needs to be shared with distributed locations.

Previous article: Feature Modeling and Task Estimation

Continue on to the next article: Start Your Engines: Iteration 0

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.