Agile Management: Avoid the "Pretty Swans vs. Ugly Ducklings" Dichotomy
This is outdated VersionOne V1 post.
I usually come across two classes of workitems in agile projects as I train, consult and coach clients at VersionOne.
- Class A workitems: Customer-driven or user-driven stories, features, epics, business initiatives
- Class B workitems: By definition, everything else. Several examples are listed below:
- Defects fixing work: Defects pushed out from earlier sprints, or reported by users in their production environment while the current sprint work is going on.
- Porting work: For example, port software from IP v4.0 to v6.0, port software from the existing database system to a different database system, port software to support multiple browsers, etc.
- Spikes: Proofs of concept, prototypes and experiments to reduce the technical risk and gain knowledge
- Develop test suites: Develop automated or manual test suites for various non-functional system-wide requirements, such as performance tests, usability tests, security tests, inter-operability tests, scalability tests, availability tests, system tests, etc.
- Run test sets: Run test suites (automated or manual) for various non-functional system-wide requirements listed above; run manual or automated regression tests sets; log defects found along with steps to reproduce the defects.
- Architecture runway work: Technical infrastructure design and coding effort necessary to support upcoming features in the nearer-term without excessive, delay-causing redesign. This type of work is becoming increasingly important as agile projects scale up. For further details, see the SAFe web site.
- Infrastructure work: Set up or improve development, test, build environments; continuous integration server; continuous delivery (DevOps) systems, etc.
- Dependency management work
- Online help, tutorials, release notes
- Technical debt reduction work
- Customer support team training
- General Availability (GA) release packaging
Often Class B work may represent as much as 30% of the total work if it is fully accounted for and properly estimated. For so-called hardening or stabilization sprints, all work is Class B work. However, Class B workitems are often not properly inventoried and logged in the agile application lifecycle management (agile ALM) tool; they are poorly estimated and poorly planned. Consequently, they come back and haunt the team during sprints as unplanned or underestimated work – sort of their revenge for not receiving the respect they deserve. These two classes of workitems are compared and contrasted in Table 1. Treat all workitems as pretty swans deserving your full attention No workitem should be treated as an ugly duckling. Here are several concrete steps I would like to recommend so you can treat all workitems as pretty swans: Ownership: If the product owner is reluctant to own or support Class B workitems, or does not have a good understanding of them, team members should have an honest discussion with the product owner about the reasons, cost and benefits of Class B workitems. The discussion has to be along the lines that if we don’t take proper care of Class B workitems, the team will continue to increase its technical debt and end up lowering productivity in the future. In fact some Class B work (such as defect fixing and running test suites) even has impact on users. On the other hand, if we spend reasonable effort on Class B workitems (10% to 20% in our view), it will lay the foundation for productivity growth in the future. If necessary, senior management (perhaps facilitated by the ScrumMaster) may need to play a constructive role here, as there is never-ending pressure to deliver more and more Class A stories demanded (or thought to be needed) by customers and users. Inventory and Visibility: There must be a full and proper inventory of all Class B workitems. They need to be logged into the agile ALM database with clear and complete description along with appropriate acceptance criteria. Analysis: The analysis methods for Class A vs. Class B workitems are different. The product owner or business analyst explains and clarify Class A workitems. Team leads (development leads, QA testing leads) and other subject matter experts clarify various Class B workitems. Analysis of both Class A and Class B workitems should be done preferably one time-box ahead of their design and development time-box, as explained in my sprint pipeline blog post. Only with proper analysis effort can one clearly understand what needs to be done for each Class B workitem -- the prerequisite for estimating, planning and the actual implementation effort. INVESTment: Class B workitems also need proper INVESTment. They need to be independent of each other (at least the specification level). They should be negotiable between the product owner and the team, with both sides coming to an agreement on the scope of the work and what is outside of the scope. Although the value for some of the Class B workitems (such as spikes, architecture runway and technical debt reduction) is not immediately relevant to customers or users, the product owner needs to understand this work is important to reduce the technical risk and to improve the productivity (velocity) of future sprints. The team members should be able to break down large Class B workitems into smaller Class B workitems that can be completed in a single sprint. Each workitem needs to be testable. Acceptance criteria and acceptance tests: Class B workitems must have acceptance criteria as agreed upon between their owners and the team, with concurrence from the product owner. Depending on the nature of the workitem, acceptance tests may be a matter of going through a checklist (for completion of release packaging or training the customer support team). Or it may be running and passing test sets, fixing, verifying and closing defects, checking that the spikes have produced the desired technical information (or if you've run out of the allocated time for the spike), online help is reviewed to match with working software, etc. Estimation of effort: This creates challenges for Class B workitems. The practice of estimating Class A stories in story points using Planning Poker or the Table-top estimation method is quite common. But what about estimating all Class B workitems? Relative size estimation is a powerful technique, but it needs to be applied to stories of the same or comparable type so you can do a sensible apple-to-apple comparison in estimating relative sizes. If you compare relative sizes of disparate types of workitems -- such as comparing stories with defects, stories with porting work, spikes with technical debt reduction, or test automation with training/online help -- the comparison and resulting story point estimates will not be very meaningful. This is one of the reasons why some teams don’t bother to estimate Class B workitems, which is a mistake, as explained above. I suggest that a team simply estimate the work effort for each Class B workitem in ideal hours, either based on the team consensus or based on estimation by experts in the team who are likely to do that specific workitem, such as a spike, porting work or online help. Many Class B workitems do need specialized expertise and it makes sense for the team member(s) to do that work to estimate it. This is a more appropriate way to estimate the effort than using relative size estimation to compare non-comparable workitems (it would be analogous to comparing apples to oranges or comparing apples to other objects like tires or stones). Once a Class B workitem is estimated in ideal hours, it is very easy to convert that estimate into normalized story points by dividing the estimate in ideal hours by the Normalization Basis chosen by the enterprise, as explained in Part 4 of my blog series on the topic of Scalable estimation and Normalization of story points. Normalized story point (NSP) = Estimate in ideal hours / Normalization Basis For example, if the Normalization Basis is chosen to be 20 hours for an enterprise, then a defect estimated to take 4 hours to fix, verify and close is equivalent to 4/20 = 0.2 NSP. A spike estimated or budged to take 30 hours is equivalent to 30/20 = 1.5 NSP. And a porting effort estimated to take 120 ideal hours is equivalent to 120/20 = 6 NSP. All Class A story points are also converted into NSPs as described in detail in my blog series on the topic of Scalable Estimation and Normalization of Story Points. Now all Class A and Class B stories will have the same scale for expressing their estimates, i.e., normalized story points. This will make all story point math, reports, and metric meaningful and accurate. Planning: Sprint planning must take into account both Class A and B workitems. After analysis and estimation steps, planning involves making sure that the planned work is consistent with historical velocity or available capacity. Let's say the team has exhibited a stable average velocity of 25 (normalized) story points over the last 3 to 4 sprints comprising of both Class A and B workitems. Then under the so-called "Yesterday’s Weather Model" (same team members, same technology platform, same application domain, etc.), the team should plan on undertaking about 25 normalized story points worth of work (comprising of both Class A and B workitems) in the upcoming sprint being planned. If the Yesterday’s Weather Model is not applicable, the team will need to do capacity-based planning considering how the team capacity will be used to perform both Class A and B workitems. The product owner should rank-order the entire sprint backlog of both Class A and B workitems using the ranking method of his or her choice. Status of Workitems: As all workitems of Class A and B are treated on the equal footing as explained above, all workitems are pretty swans. There should be no ugly ducklings. Planning, execution and retrospectives will all benefit from this approach. And the teams, projects and organization can only benefit. Do you have any ugly ducklings in your agile project backlog? Can you think of any ugly ducklings that are not included in the Class B workitems list? Remember that ugly ducklings often have a disruptive effect on the well-planned work for pretty swans. Ugly ducklings can turn pretty swans into ugly ducklings, too. Do resolve to treat all your workitems (both Class A and B) as pretty swans. From your team’s successive sprint retrospectives, your team should be able to judge whether the problems caused by ugly ducklings are going down steadily, sprint by sprint; if not, what corrective actions must the team take? Many corrective actions are presented in this blog (see the concrete steps presented above). In short, avoid the pretty swans vs. ugly ducklings dichotomy. I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com) or on Twitter (@smthatte).