Johanna Rothman Report Your Project State Chapter 14 Copyright © 2017

Project Pyramid: Tradeoffs & Potential Risks for Projects Inside the developers are responsible for managing their project risks Outside management is responsible for managing their project risks

Rothman “… the Product Owner defines and the team implements small vertical slices that help people see the minimum skeleton of the product” Actually, the Product Owner is responsible for identifying all the needed Features and the user requirements for each Feature As a result, the Product Owner should want to see “Go-live pieces of the product” … not merely a skeleton of the work needed and the WIP yet to completed

Product Backlog Burnup Chart Yes, “customers buy features” but the Product Owner is responsible for articulating each feature and the user needs associated with each feature Cumulative Features Iteration or Interim date

Product Features Complete, Remaining, Total Total features added from the team’s initial guess Features Remaining Features Complete Total Features Features Burndown from the initial guess Time

Show other requests on the team The question: “When will the project be done?” The interrupts and the resulting uncertainty… “Sometimes managers don’t realize they are asking the team to multitask” Hard to imagine that “managers” would not know the impact… unless the hard to imagine is driven by pressure from “higher” ups! … so, as suggested, show the impact… the number of “requests” Rothman “… consider creating a chart, such as the one outlined in the following table…”

Show Other Requests of the team… Is Project B more valuable? If so, why worry about the effect of multitasking! Some or all of the team might do the work on Project B… … fully understanding the interrupt effect on the current project! Could management not know the multitasking causes delays? Could management not know that teams are more apt to create defects when they multitask?

Work That’s Done & Not Yet Released cards on the wall Why “Anticipated Release” does not have a full set of cards… … because the team doesn’t know when it will have enough of a given feature actually done!

WIP With WIP the team is not capable of releasing … features can not be released! … the Work is not done! The decision as to when and what to release is a collaborative decision between the Product Owner and the team! Business savvy is important for the Product Owner … he or she is the decision maker regarding what features the product will have… and what and when features should be released That means, the agile PO understands the market, the customer and the business in order to make sound decisions

Locate and Visualize your Project’s Delays T0: Item selected T1: Item is on the team’s backlog T2: Some people on team 1 start to work on it T3: Other people work on it T4: Everyone agrees it is done T5: Release to users --- cycle time --- ------------------- lead time ------------------- T1: On a team’s backlog

Table 13 - Calculating the Cost of Delay for Each of Three Features CD3 decision principles as three simple rules: When delay costs are homogeneous, do the shortest job first. When job durations are homogeneous, do the highest-cost-of-delay job first. When job durations and delay costs are not homogeneous, use Weighted Shortest Job First (WSJF).

When to use the “Cost of Delay” The team is multitasking… whether it’s the team or management induced… … could the managers see the resulting delay before they see value of the work? The team is waiting for others… this would happen if the team did not have the “skill sets” necessary to complete the work The team cannot release its completed work … waiting for others needed to deploy their “done” work Rothman’s suggestion to have the team rank the “work” This is the “role” of the Product Owner … who from the start collaborates with the team in ranking all of the work… the features and the user stories associated with each feature!

Rothman’s Project Measurement Traps Managers look at the team measures instead of project status measures. Mangers try to compare teams using velocity or some other team-based measure Too few people review the cost-of-delay measures … which can create risks when the team has significant WIP

TRAP: Managers look at the team measures instead of project status measures “Velocity is easy to measure… if teams have large features … feature sets … progress is difficult to see. … managing velocity doesn’t help anyone understand the team’s progress.” Well… SCRUM Velocity is a measure of the “story points” that are “done” at the end of an iteration Retrospectives provide the team with the “learning” needed to improve their estimates of how much to pull into the next sprint… velocity is not used as a constant measure for each iteration!

Interesting recommendations “… avoid showing manager’s a team’s velocity… If you must, explain the team’s capacity. Better yet, ask the manager what information they want…” The following is expected to defer judgement! … ? “You might say something like… That feature isn’t on the roadmap (?) for another three iterations… once we get closer, we can use cycle time … the average time it takes us to release a feature … to tell you more about when in the iteration you might see it.” That sounds like a unique confidence builder.

Trap: Managers try to compare teams using velocity or some other team-based measure Sometimes (?) managers don’t realize what velocity is Velocity is a measured end of sprint result… so many story points “done” Assuming the team is learning after each sprint … and improving story points “done” in subsequent sprints… sprint velocity increases Yes… velocity is unique for each project … different features and different user stories … the work is not a repeat of the work previously done … which always the case Yes… teams within the organization vary in lots of ways! What could be a good definition for a competent manager?

Trap: Too few people review the cost-of-delay measures … which can create risks when the team has significant WIP “Teams have WIP for many reasons” If there are external causes (team “interrupts” … these should be addressed) If WIP remains unchanged or grows from sprint to sprint… the team’s technical and collaborative skills should be assessed… The process is broken if the Product Owner and the Team are not closely collaborating before after every Sprint

Rothman’s suggestion for the team Make WIP visible (if should always be visible… what is not “done” is still part of the Product Backlog!) Measure the cost of delays… CD3 assessments can identify what work should be done and in what order, but all the work still needs to be completed “Create WIP limits” At some point (limit) no additional work is to undertaken until WIP is reduced and work gets “done”