Discretización temporal y número de Courant

this state is almost never easy. It requires evaluating cost-benefits, analyzing trade-offs, compromising, and collaborative bartering. It is the right of the customer community to set priorities, but the technical community must provide input and guidance in the process.

Backlog Management

Once the backlog is established and prioritized, it must be continuously maintained and managed. User stories move off the backlog in priority order as they are scheduled into an iteration for development. When they are completed and accepted, they are marked as such. The product owner and customer community have the responsibility of continuously reviewing and refining the backlog. As new knowledge about the BI system and the busi- ness needs unfolds, the priorities may change. As the project community gains clarity on certain stories, they may become obsolete or change. At any given moment, the backlog should reflect the most current understanding and prioritization of user features. Whenever the development team has an opportunity to work on something new, there should be no debate that the next most important thing is the story card that is at the top of the backlog.

The identification of user stories is never absolutely complete. During release planning we strive to identify a comprehensive set of the most important stories, but during the project stories will be redefined or eliminated, and new ones will be written. I’ve worked on many BI projects in which story definitions evolve as users’ understanding of BI solutions matures. Don’t be afraid to tear up a story card if it no longer seems relevant. If it turns out to be important, it will resurface later.

Agile Analytics Practice: Continuous Backlog Grooming

The product owner, in partnership with the co-development customers, should pay continuous attention to the product backlog. Grooming the backlog includes shaping the user stories, reprioritizing them, and add- ing new details as they are discovered. Doing this will ensure that the backlog is an accurate reflection of what is planned.

S

-P

E

In addition to writing the book on user stories, Mike Cohn is the authority on Agile estimating and planning, and his methods apply very appropri- ately to Agile Analytics development (Cohn 2006). This section serves as

ptg6843605

an introduction to Mike’s techniques but is not a substitute for reading his more comprehensive treatment of this complex topic.

First let’s acknowledge that we aren’t very good at accurately estimating development effort and complexity. Traditional phased project management focuses on breaking down work into tasks and activities (work breakdown structures), estimating the person-hours required to complete each task, parallelizing wherever possible, then adding it all up to get an overall project time estimate. The success of the project is measured in terms of how well the team executes to the plan.

There are numerous reasons why this approach doesn’t work. Each task estimate has error built in, and all that error gets added into the project total. Estimating is done up front when project uncertainty is greatest. It doesn’t incorporate frequent replanning and re-estimating opportunities to make adjustments and corrections in light of new knowledge. Estimates become contractual obligations, so they get artificially padded at each step in the process. Estimation is often in terms of developer hours per task, which doesn’t account for multitasking, distractions, and other external influences.

One of the biggest reasons work breakdown structure estimating doesn’t work is that you cannot estimate tasks without really understanding the “product.” Stories force you to understand the product and the customer value it represents first.

Imagine that you are asked to estimate the distance from your workplace to your home in centimeters. Assuming you live a reasonable distance from work, it’s going to take you a lot longer to evaluate the distance in centime- ters than it would in kilometers or miles. In fact, you’ll probably start out estimating in a coarser-grained unit like kilometers and then converting to centimeters. (If you live in the United States you may take even more con- version steps.) It isn’t appropriate to estimate large, uncertain things like long distances in fine-grained units like centimeters; nor is it appropriate to estimate project lengths in fine-grained time units like developer hours or even days.

Painters use square feet of space to estimate the cost of a painting job. For years software developers have looked for a similar unit of output to esti- mate. Both the early use of lines of code and later use of function points attempted to be this “unit.” Unfortunately, both can be estimated only late in the development process—they were developed to complement a water- fall lifecycle process. Agile developers needed something new.

ptg6843605 STORY-POINT ESTIMATING 113

Story points are a nebulous unit of effort that enable us to avoid using clock time or developer time. Story points are relative. A 100-point story is expected to take twice as much effort as a 50-point story and half as much effort as a 200-point story. The actual point values are irrelevant so long as the development team uses its point scheme consistently.

To illustrate the concept, consider how you might select a car at the ACME Car Rental agency. They offer economy, compact, midsize, standard, full- size, and minivan classes of vehicles. Now it isn’t really necessary to estimate the precise differences in the bumper-to-bumper length or interior volume of each car class to decide which class you need. Let’s start with the stan- dard car class and assign it an arbitrary value of 10. Since a minivan is about twice as large, we might assign it a point value of 20. The economy class gets a 6 since it isn’t fully half as large as a standard but still significantly smaller. We’ll assign the compact class 8 points, and the full-size class 14 points. Now we have a set of “car points” that describe the relative differ- ences among these car classes. As long as we understand and agree upon our “car points” scheme, these numbers are relevant and meaningful.

We can do the same thing with user stories since some of them are relatively simple and straightforward while others are complex, risky, and uncertain. The numbering scheme you select for story points should reflect the notion of relativity. Two good numbering schemes are {1, 2, 4, 8, 16} and {1, 2, 3, 5, 8, 13}. The first one works because each number is simply two times the prior number. The second one is the first six numbers in the Fibonacci sequence starting at 1. This is meaningful because the gaps in the sequence become larger as the numbers get larger. This supports the goal of clearly separating bigger story estimates while allowing smaller ones to be a bit finer-grained. Numbering schemes like {1, 2, 3, 4, 5, 6} aren’t a good idea because they promote unnecessary debate about whether something is a 5 or a 6 since these numbers sit so close together. If you really want to appear impressive, choose large numbers like {100, 200, 400, 800, 1,600} which will give the impression that the team is very productive.

To bootstrap the estimating process we must have a starter story to estab- lish a point of reference. First, let’s agree to use a {100, 200, 400, 800, 1,600} story-point scheme. Second, let’s choose a moderately complex story and assign it a baseline reference value of 400 (see Figure 4.10). The reference story doesn’t have to be one of the new user stories. If there is a story avail- able that has already been implemented, and the team is familiar with it, this is a good candidate for the baseline reference. Ideally this reference story is not overly simplistic or complex. It should be of relatively moderate complexity.

ptg6843605

From this reference we now have the ability to assign story-point estimates to other stories by asking the questions “Is this harder, easier, or about the same as our reference story?” and “How much harder or easier?” Now in relative (and approximate) terms we can assign point values to the other user stories (see Figure 4.11).

The beauty of estimating in story points is that it keeps the team think- ing in coarse-grained terms, which is akin to estimating long distances in kilometers rather than centimeters. There will be times when a team mem- ber might say something like “This is more than a 200 but less than a 400.” Avoid the temptation to use point values between your agreed-upon values.

As a profitability analyst I need the ability to examine

customer profitability by customer type so that I can

anticipate future profitability. ₄₀₀

Figure 4.10 Story-point reference baseline

As a profitability analyst I need the ability to examine

net profit per customer per transaction for any customer

so that I can identify the customers who might become

more profitable. 200

e

As a profitability analyst I need the ability to examine

gross profit per customer per transaction for any customer so that I can identify the most

profitable customers. t

As a profitability analyst I need the ability to examine

customer profitability by individual store per day so

that I can help the least profitable stores become

more profitable.

. . . 200

800

As a profitability analyst I need the ability to examine

customer profitability by customer type so that I can anticipate future profitability.

400 Figure 4.11 Relative story-point estimates

ptg6843605 STORY-POINT ESTIMATING 115

Restricting estimates to a small, discrete set of point values will help the team avoid overthinking these estimates. When in doubt on a point value, take the more conservative estimate to allow for the unknown tasks. If it turns out that a story is easier than you originally estimated, you can cel- ebrate the earlier completion of a feature.

It is the right (and job) of the development team to estimate effort in story points. It is essential that the entire development team be involved in the estimating process. This practice has two distinct benefits. First, it ensures buy-in and ownership by the entire development team. Team buy-in and ownership are critical components of the success of self-managing teams. Second, it injects a sort of “checks and balances” into the estimating pro- cess. When everyone agrees on an estimate, the team quickly moves on to the next story. However, disagreement on the estimate suggests that either team members have differing understandings of the story or there is a high degree of uncertainty or risk in the story.

Don’t be tempted to expedite the planning process by having the project manager, technical lead, or chief architect handle the estimating single- handedly. When the entire team is involved in planning and estimating, there is tremendous value in the conversations that ensue. Collaborative planning generates questions whose answers lead to greater clarity of under- standing by all team members. It creates early opportunities to identify risk and uncertainty. And team planning ultimately leads to a galvanization of the product vision. These gains are well worth the time required for collab- orative planning.

Development velocity is the key to the effectiveness of story-point estimat- ing. Velocity is the demonstrated number of story points a team is able to complete and have accepted in a single iteration. A team’s capacity is its steady-state velocity after the team establishes its sustainable development pace or rhythm.

Suppose a team commits to the completion of four user stories at the begin- ning of an iteration. The point values of these stories are 100, 400, 200, and 200 for a total goal of 900 points. If the team finishes all four stories, but the customer community accepts only the last three stories based on the accep- tance criteria, the team velocity for that iteration is only 800, not 900. The remaining 100-point story is not finished until user feedback is addressed and the customer community accepts the feature. This highlights the importance of developer-customer collaboration and the clear definition of acceptance criteria. Nonetheless, user expectations are always subject to change, and we must embrace and adapt to that change.

ptg6843605

Monitoring velocity establishes the basis for the next iteration plan. A devel- opment team should not commit to more points than its demonstrated velocity. Even though our hypothetical team did more than 800 points worth of work, it should commit to only 800 points for the next iteration. Now suppose the team commits to finishing the 100-point story plus three additional stories with point values of 100, 200, and 400. The effort required to finish the “hangover” story is minimal, and the team finishes all 800 points of work at the beginning of the second week of a two-week iteration. It now has the option of plucking one or more additional stories from the backlog (or the next iteration plan). The team collectively agrees to com- mit to an additional 200-point story. At the end of the iteration the features are showcased to the user community and are all accepted. The team’s new demonstrated velocity is 1,000 points, so it can now make the next iteration commitments based on this velocity.

Another benefit of tracking velocity is that it enables the project community to anticipate the cut line on the prioritized backlog. The cut line is an imagi- nary line on a theoretically infinite backlog of user stories. The cut line rep- resents the volume of story work that can be completed by a development team during a timeboxed project cycle. Since the team’s capacity is finite, the project timeline is bounded, and the backlog is prioritized according to business value—the project community can anticipate which, and how many, stories will be delivered during the project cycle.

When an Agile team begins a new project, or a new team is forming, it may take several iterations for the team to match its velocity to its true capacity. During this time it is important that the team base its current commitments on the previously demonstrated velocity. This supports the well-known principle of undercommitting and overdelivering. I have worked with many new teams that succumb to the pressure to overcommit during early itera- tions. When they don’t meet their commitments, they are demoralized. It is much more gratifying to celebrate a boost in velocity through overdelivery than to be discouraged by overcommitment.

Over time every team will establish its steady-state capacity. Capacity and velocity should not be used as productivity metrics for comparing one team with another, or one project with another. Capacity and velocity should be used only within a project to monitor whether the team is operating at peak efficiency. Planning should always be capacity-based. A project community should base project plans and expectations on the actual capacity of the team. Avoid the temptation to do what Jim Highsmith calls “wish-based planning.” Business intelligence projects almost always have the natural tension between the desires and wishes of the customer community and the finite capacity of

ptg6843605