Product Backlog Grooming

Download Product Backlog Grooming

Preview text


Many of our customers blend Scrum and kanban frameworks when organizing their agile development projects. Every implementation is different, making it hard to generalize about where agile test estimation fits in. Test planning typically is not treated as a distinct, separate activity, but rather testing tasks are planned as part of the work done to fulfill requirements. Estimation takes place during backlog-grooming meetings and sprint-planning sessions.
Traditional software development lifecycle projects often are sufficiently large and complex that estimation becomes a point of contention. Estimating the productivity and failures of dozens of people you’ve never met can be hazardous. Waterfall estimation can be top-down, and it can be back-to-front—for example, when we are scheduling backwards to fit the work into a known deadline or a budget constraint. Or, estimation

can be bottom-up, rolled up from lower-level components of estimates. These estimation techniques tend to have to assume observations at five meters from ones made at 50,000 meters.
In our experience, iterative agile projects produce better estimates than traditional waterfall development. During both product backlog-grooming meetings and sprint-planning sessions, the vision is usually clearer, the time scale smaller, and the planning horizon closer. Continuous improvements are expected and accommodated, rather than resisted. Quick feedback loops and refinements of project goals and deliverables are built into agile processes. Communication tends to more immediate, open, and informal. Estimates are developed more quickly and accurately, with less effort, and politically are easier to revise.




Product Backlog Grooming
Product backlog grooming involves the careful review and improvement of product requirements well in advance of their implementation. The product backlog is a prioritized list of requirements including user stories, features, non-functional aspects of the system, product deliverables, and constraints. Lower-priority backlog entries have less detail, while higher-priority backlog entries have more detail.
Grooming sessions help the team elicit some detail from the product owner, customer, user, or business analyst. When a backlog entry is groomed, the team develops a common vision of what the requirement is and why it is important to the customer. During a session, the team elicits acceptance criteria for each story. The acceptance criteria often are stated as a series of examples from different perspectives showing what a successful implementation would look like.
During grooming sessions, the team estimates the size of high-priority stories with a unit of measure called a story point. A size is assigned to each backlog entry proportional to implementation effort. Story points are team specific and relate to real, recent, relevant experience.
To come up with an estimate, the team plays a few hands of planning poker. First, each team member receives a set of cards with possible sizes: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ?. Second, the product owner reads through the story being sized. Third, team members vote for the size they feel fits best based on their past experience. Fourth, differences are discussed to resolve disagreement and build a better understanding and consensus. The team members who suggested the smallest and largest sizes advocate their estimates. It can take a few rounds of poker to size a story. Finally, the estimate is completed when all team members are within one card value of each other in the size estimate. The higher value is selected as the size estimate for the backlog entry.
After a few sprints, the team’s effective burn rate measured in story points per day should be known within a tolerable range of uncertainty. This burn rate is often called a team’s velocity and is used as a basis for downstream product estimation and planning. For example, if a team can implement fifty story points per sprint, then the product owner can estimate that within ten sprints the team can probably implement about 500 story points’ worth of functionality. Velocity measures a team’s productivity.
Estimating Guidelines—Horizon vs. Level of Detail
We usually have less information about tasks that are further into the future. The relationship between the time horizon (how far the planning looks ahead) and the level of task detail (sampled from recent projects) can be seen in table 1.
At the beginning of each sprint, the agile team holds a planning session to identify work required to implement high-priority backlog entries. During the planning meeting, the team identifies technical work required to implement each backlog entry. The team

Table 1: The relationship between the time horizon and the level of task detail. *We reversed the sequence of entries in the task detail column—e.g., "8 to 4 person-hours", instead of "4 to 8 person-hours"—in order to highlight the inverse relationship between planning horizon and task detail.




considers activities related to designing, programming, testing, documenting, and training, and the team and product owner define what it means to be “done.” For example, a story might be done when:
• The story is coded. • All story code is integrated into the product’s main code
line. • The story programming tasks are completed. • The story data-related tasks are completed. • The story testing tasks are completed. • The story documentation tasks are completed. • The story training-related tasks are completed. • Story-related unit tests pass. • Story-related acceptance tests pass. • Product regression unit tests pass. • Product regression story tests pass. • Story non-functional acceptance criteria are confirmed. • Product performance is acceptable. • The product is robust as demonstrated by passing stress
tests. • The product can be installed. • Customer data can be migrated from the previous ver-
sion. • Auditable evidence exists of regulatory compliance
testing. • All known bugs in the product are acceptable to product
The scope of work can radically change the story size. Without a uniform definition of “doneness,” underestimates by factors of one to three or worse are not uncommon. (Special application of Murphy’s Law: In an orderly, rational world, underestimates and overestimates should balance out. In practice, all incorrect estimates seem to be underestimates. Sabourin’s thesis: The problems of underestimating are most visible only when they will prove to be most embarrassing.)
The entire team collaborates to identify the approach that will be used to implement the backlog entry. Very often, a backlog entry is defined by a user story that involves changes to several tiers of an application, including the data layer, business logic, and presentation layer. Different design alternatives are discussed from the perspective of benefits and risks.
When the approach is chosen, the team itemizes tasks required to implement the backlog entry, conforming to all ac-
Table 2: Baseline estimates taken from similar projects.

ceptance criteria and meeting the team definition of “done.” Team members with testing skills have a lot to contribute to this discussion and are urged to identify specific tasks. The types of testing tasks for each backlog entry include infrastructure related, data related, customer facing, non-functional testing (experiments or study), robustness, exploratory test charter, regression related, development facing, and business rules related.
Some agile teams assign an effort estimate to each task, showing the amount of work in person-hours needed to complete the activity. Teams usually use an activity granularity of about one-half day to two days per task. The ScrumMaster can use the estimate to track effort to finish as tasks are completed. During the sprint, the ScrumMaster tracks the remaining effort and takes steps to ensure work allocation is well balanced between the different team members. Because of the relatively rapid rate of iteration, it frequently is unnecessary to re-estimate the initial estimate within an iteration. Instead, the calibration is done from iteration to iteration. A table of estimates that at the beginning of the project are, let’s say, 80 percent derived from external experience is gradually replaced with the project’s own internal data as confidence grows. The deltas among estimates and actual efforts should converge nicely after a few iterations. Of course, if the deltas among estimates and actual efforts diverge, it is back to head scratching and Murphy’s Law.
Example of a Task-Estimating Table
An electronic data system team began collecting estimation data to help improve task-effort estimations during agile projects. As the project continued, they refined the accumulating data, merging calibrated data based on actual efforts as observed during each project sprint. The team started by using the baseline estimates in table 2, taken from previous similar projects. Note that estimates are hours per task and organized by the type of testing task. Complexity is assigned four levels: minor, moderate, major, and extreme. Although these are subjective assessments, the team can reference recent relevant examples of each task’s complexity levels.
During each sprint, the EDS team tracked the actual hours required per task and updated the baseline values with their project averages (see table 3). The ratios in the merged results were derived from the team’s familiarity, confidence, and relative stability of the data.
Other Agile Estimation Approaches
Here are some alternative estimation approaches we have encountered. Teams often combine one or more of these techniques.
T-shirt sizing: Backlog entries are classified as being small, medium, large, or extra-large.
Size complexity: The team assigns a size and complexity to each story. Low-complexity entries are extensions of existing behavior. Medium complexity involves implementing new code or algorithms. High-complexity entries involve many variables and addressing new concepts. Size and complexity are used to




Table 3: Actual effort required per task in hours.
estimate effort based on past data. Three-point estimates: When esti-
mating a task’s effort, instead of just estimating one value, the team estimates three values: the optimistic value, or what effort would be required if everything went perfectly following the socalled happy path; the pessimistic value, or what effort would be required if Murphy’s Law kicked in and everything that could go wrong actually went wrong; and the most likely value, or what effort is typically required to complete this task. Once the team has these three values, a formula called the program evaluation and review technique (PERT) formula can be used to come up with the team’s task-effort estimate:
The three-point estimation approach is popular among members of the Project Management Institute and is explicitly referenced in their Project Management Body of Knowledge.
Some Concluding Remarks
Test estimation in agile teams is tightly coupled with planning. Groomed backlog entries with clearly defined acceptance criteria should be sized by the team responsible for implementing them. Agile planning sessions are collaborative team activities in which design and implementation alternatives are explored and a task list is created describing the actual work to be done. When tasks are identified, teams can estimate their respective effort. When testing activities are broken down into tasks, any suitably skilled and qualified team member can do them. Breaking down tasks to imple-

ment stories enables teams to estimate and track the effort required to implement backlog entries and redistribute work across different team members. {end}
[email protected] [email protected]

For more on the following, go to I Further Reading


Distinguish yourself from your peers and gain a competitive edge

Attend class in-person or virtually from office/home

Technology and Methodology Courses

HP: Quality Center ALM, QuickTest Pro, and LoadRunner

Microsoft: Test Manager, Coded UI, and Load Test

Process Improvement: ISTQB Certification, Managing Change, Requirements Definition, Enterprise Quality

Interactive Learning Method™
Bring your Workplace to the Classroom & Take the Classroom to your Workplace™

Post Training Support
Free refresher courses
Process and tool implementation services

Bulk Training Program
Savings of up to 40% with credits good for a year

Since 1993, ALPI has empowered clients with innovative solutions delivered by our staff of flexible and creative professionals. Trainings are held virtually, at our state-of-the-art facility located just outside of the Nation’s Capital, or onsite at your company location.
Contact [email protected] or 301.654.9200 ext. 403 for additional information and registration details




Preparing to load PDF file. please wait...

0 of 0
Product Backlog Grooming