1. Johanna Rothman Report Your Project State Chapter 14
Copyright © 2017

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

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

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

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

6. 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…”

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

8. 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!

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

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

11. 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).

12. 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!

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

14. 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!

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

16. 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?

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

18. 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”