Feature Modeling and Task Estimation

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

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

This topic contains the following sections.

• Clearly Defining the Goals: What Is “Feature Complete”?
• Using Feature Modeling to Identify and Estimate Tasks
• Identifying and Estimating Tasks
• Copyright

When you plan for a release, you estimate features at a high level using story points and measuring relative size. This lets you envision the entire release and communicate the timeline to parties who have an investment in the project.

When an iteration begins, you should understand the work being pursued in detail so the team can understand the tasks and feel confident that they can deliver the features assigned to the iteration. The team will increase their confidence by estimating the identified tasks in hours needed to complete the work, and they will compare the estimates to how much capacity they have in hours available for the iteration.

A key part of iteration planning is a clear definition of what complete or done means. Let’s start our discussion of iteration planning by defining done.

Clearly Defining the Goals: What Is “Feature Complete”?

When you create your feature cards, you record acceptance tests. These acceptance tests help you focus on delivering to the minimum requirement and also verifying that a feature is complete.

We suggest reviewing the acceptance tests at the start of iteration planning. The team needs to have a good understanding of what success means before breaking down the work and identifying the tasks needed to complete it.

A good way to kick off iteration planning is to have the customer explain the acceptance tests that have been recorded on the feature card. The team can ask more questions about the tests, and a tester can document the tests in more detail during the discussion. This may mean creating the tests in a testing tool such as TestDirector.

Note

The tests you create should be in boolean terms, meaning that the test results can be viewed from a true or false perspective.

For many teams, the customer can’t be available for every build and can’t test every feature as it’s delivered, so a tester performs the daily tests. If a feature passes, it’s queued for eventual approval by the customer. In the case of Acme Media, the customer performs user acceptance testing at the end of each iteration.

Using Feature Modeling to Identify and Estimate Tasks

To this point, Acme Media’s team has struggled to not jump into a detailed design session for each feature. Even though they’ve been performing just enough planning to create a release plan, it’s natural for a team to begin envisioning technical solutions as soon as they see a feature description. When your release plan is complete and you need to start working on the first iteration, you turn the team loose and let them break down the features into detailed tasks and estimates.

We cannot prescribe one perfect method for breaking down your features. You may be able to understand the required tasks through team discussion, or you may find that you need to create wireframes or mockups to understand the work that will be required. Some teams can effectively identify tasks by creating use cases for the feature cards and envisioning the system needed to support the use cases.

One process that we’ve found effective is feature-card modeling. This technique is focused around user interaction and screen design, and many teams find that the exercise lets them learn enough about a feature to identify the required tasks. Here are the steps you follow to perform a modeling session with your project team:

1. Select a feature card.

2. Outline a workflow for the feature.

3. Create new feature cards for features that are discovered in the workflow.

4. Outline the screens needed to support the feature.

5. Add detail to the screens, considering user and system interaction.

6. Identify the major tasks needed to build the feature.

7. Estimate the identified tasks.

If modeling is new to your team, you should involve the entire team the first time you use it. After this training, they can break into subgroups in future sessions and model several features concurrently.

The customer should be highly involved in the modeling sessions. The project team will have many questions for the customer as they probe for deeper understanding of the requirements.

Let’s Watch Acme Media as It Models One of the Features for the Auctionator.

Outlining the Workflow for a Feature

Acme Media will model feature 10, the ability to bid on an item. The first thing the team does is outline how a buyer arrives at the bid screen.

The team envisions that the buyer will perform a search from the auction home page. The search will bring back a list of results the buyer can choose from. The buyer will then choose a listing and view the details of a specific auction. The team outlines this workflow on the whiteboard (Figure 16.1).

Figure 16.1 A first pass at a workflow to support a feature

The team then discusses what the buyer can do once they arrive at an auction detail page. They note the following:

• The buyer must be logged in to place a bid from the auction detail page.

• After the buyer places a bid, they will want to watch the auction and monitor the status of their bid.

• The team thinks about the ability to retract a bid. Is that functionality required?Jay, the customer, listens in and determines there is a need to support bid retraction.

• The team also discusses the ability to “buy now.” In essence, that’s what Acme’s classifieds site does. With input from the customer, the team determines that they will have “buy now” functionality.

• The team notes that several processes must be triggered when an auction closes.

You can see their whiteboard notes in Figure 16.2.

One of the common occurrences during this exercise is the identification of previously hidden features.

Figure 16.2 The workflow surrounding the ability to bid. As the team discusses the feature, additional questions surface about system interaction.

Discovering New Features

The team now lists the additional feature cards that have been discovered during their workflow exercise (Figure 16.3). These features aren’t on the current list provided by the customer; they need to be encompassed in existing cards, or new cards must be created for them.

Figure 16.3 Identifying new feature cards after reviewing the workflow

The team decides that the ability to monitor an auction is an intrinsic part of the bidding process. Monitoring and viewing auction details will be included in the scope of the ability to bid feature. The team creates new feature cards for the other discoveries:

• Feature 15. The ability to retract a bid.

• Feature 16. The ability to purchase an item immediately.

• Feature 17. An auction engine. The team has identified several processes that the system needs to manage, such as tracking the highest bidder, emailing the winning bidder and seller, notifying the seller if no one bids, and tracking the time left in the auction.

The team now has a clear understanding of the scope of the ability to bid feature. They will take ownership for viewing auction details, entering a bid, and monitoring an auction/ bid (see Figure 16.4).

With the additional features defined, the team is ready to examine the user screens in detail.

Figure 16.4 Outlining the scope of a feature

Outlining the Screens for a Feature

With the scope defined, the team outlines the screens that will be needed to support bidding. They envision four screens to support the process:

• A screen to view auction details. The buyer will arrive here after selecting an auction from the listings provided by the search feature.

• A screen to enter a bid. The screen will tell the buyer the amount needed to be the high bidder. The bids will be in graduated amounts.

• A screen to review and confirm a bid.

• A bid confirmation from the system to the buyer. The team isn’t sure whether to provide a confirmation via the screen or to append it to the auction-detail screen to confirm the bid.

The screens are shown in Figure 16.5. After you define your screens at a high level, you can begin to define detailed system interactions.

Figure 16.5 Identifying the screens needed to support a feature

Adding Details to a Screen by Considering User Interaction

Now that you know the scope of your feature and the probable screens, you’re closer to your goal of identifying the tasks that will be required to build the feature. The final step is breaking down each screen to understand user and system interaction in more detail. Let’s start with the View Auction Details screen shown in Figure 16.6.

The team outlines the fields for the auction detail screen. The picture (photo), text description, and location will come from another feature, the ability to place an item up for bid. The seller provides this information when they put their item up for bid.

The team envisions receiving the current bid and time remaining from the auction engine.

The other items on the screen are links to functionality that will be delivered from other features, such as the ability to send an auction to a friend, the ability to contact the seller, and the ability to view seller feedback. The team also envisions a search box to let the buyer search for other auctions. The only remaining item is the link to place bid. This will take the buyer to the screen for placing a bid.

Figure 16.6 Adding details and fields to a potential screen. A detailed screen increases the understanding of a feature, which leads to more accurate work estimates.

The team goes through this exercise for each screen related to the ability to bid on an item. Then they go through the exercise for each feature. At that point, the team can identify all the tasks needed to complete the feature.

It is important to reiterate that the modeling work is happening just before an iteration begins, and the work is performed for only the current iteration. We do not want to waste time modeling features that may never be pursued because of the customer changing their mind or the scope of the project changing.

Is Modeling Worth It?

Some people will review the modeling exercise we’ve just outlined and question the effort. You tie up the entire project team for one day to model all the features. At the end of their work, the team has created no code, written no HTML, and performed no database work. The team spends the whole day talking about features. What is the value?

Here it is:

• The team has a deep, common understanding of the customer’s needs.

• The team has a feel for the scope of each feature and what they need to do to support the feature.

• The team has contributed to the discussion and identified issues before development starts.

• The team has a feel for how the features tie together.

The improvement in team performance due to the modeling exercise easily outweighs the time lost doing “actual work.” This exercise is necessary work—it’s every bit as important as coding, and maybe even more so. Code is worthless if it does not support the customer’s needs.

We’ve noticed a funny thing: we see teams skip modeling and then get confused about features mid-iteration. The team calls a quick, impromptu meeting and begins modeling a feature without realizing it. We suggest that you accept feature modeling as a reality of software development and do the work up front. It will reduce your overall cycle time for delivering features.

Identifying and Estimating Tasks

In the modeling exercise, you identify the screens needed to support the features. We also discussed how those screens interact with the application at large. You use this information to create your estimates. Your team reviews the workflow and screen layouts to identify the tasks they need to complete to build the feature. After they identify the tasks, they estimate them. To see this in action, let’s review the feature card that Acme modeled: the ability to bid on an item.

Acme has identified four screens for this feature:

• View auction details

• Bid entry

• Bid review

• Bid confirmation

The team has also laid out the fields for each one of these screens and discussed system interaction related to the screens. Based on this information, the team enters their tasks and estimates for each feature. You can record the information on the back of the feature card or in a project tool; Acme Media’s team recorded the estimates for the ability to bid on an item, as shown in Table 16.1.

Table 16.1 Recording tasks and estimates for a feature during modeling

Tasks	Group	Assigned	Estimate
HTML for 4 screens	UI	Ryan	16 HRS
Design data model	Dev	Roy	16 HRS
Code to handle insert, update, delete	Dev	Roy	8 HRS
Create tests	QA	Rich	2 HRS
Interface with user registration	Dev	Roy	4 HRS
Error handling	Dev	Matt	8 HRS

The team does this task-identification exercise for each feature, starting with the features ranked as the highest priority by the customer. The team repeats this exercise, estimating and adding features to the iteration, until they believe the iteration is full and they can’t take on any more work. The team is committing to doing the work versus having a schedule forced upon them.The team still uses a process to help them determine how much work they can take on, but they make the ultimate decision about what to take on regardless of what the estimate and capacity tools imply.

Note

Task Assignments Aren’t Permanent

Some people suggest not making any task assignments before an iteration begins. They prefer to have team members pull tasks as they’re available, working their way through the backlog of tasks without formal assignments.

In our experience, we’ve seen this approach work; but two items affect the value of ad hoc assignments. First, you’ll probably have team members with specialties when you begin using an Agile process. You won’t have the capability for anyone to take on any task—you’ll have to assign certain tasks to certain team members. Related to this issue, if you work in an enterprise environment, it may take several years to develop the knowledge needed to be effective in delivering software in your environment.

Second, when teams model features, they may break up into groups and model several features in parallel. When this occurs, the team members participating have a more detailed understanding of the features, and they’re better candidates to work on those features.

We suggest developing your team to a point that anyone can do any task, but this will take time and is rarely possible when you’re first moving to Agile.

Let’s look at how you determine iteration capacity.

Previous article: Release Planning: Envisioning the Overall Schedule

Continue on to the next article: Determining the Hours Available in an Iteration

Copyright

©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.