Team Practices Group/Burnup Charts/Status 2015-08-31

The Team Practices Group (TPG) was dissolved in 2017.

tl;dr: Phragile is progressing, but probably won't meet all our needs. Plogiston probably needs to be productized. We should probably set up weekly burnup meetings (UPDATE: Arthur suggests not doing so at this time), because this looks like a massive social undertaking. Kevin would prefer to hand off phragile Product Ownership to someone else.

---

Joel and Kevin met, and talked about burnups (in general), phragile, and phlogiston (the python/SQL/R solution). It was only a half-hour meeting, so we didn't get very deep into any single topic.

Joel identified these potential general burnup (and beyond) requirements, of which phragile will only handle #1 and #2:

1. Sprint burnup (scope vs burnup for 1 sprint)
2. Product burnup (scope vs burnup for whole project)
3. Stacked product burnup (separate scope line for each sub-project)
4. Diagnostic etc
   • lead time/cycle time, age of resolved, age of backlog
   • velocity
   • overall scope change
   • maintenance fraction
   • data for forecasting

The relative values and priorities of #3 and #4 need to be determined. Without discussing it with the TCB team, it seems unlikely that phragile could easily be extended to handle them, which leads to the conclusion that plogiston might need to become an actual strategic long-term product for us.

The phragile folks seem to be making great progress toward handling large projects, so it seems likely that it will start working with the massive VE Phabricator project within a couple weeks.

Joel enumerated a list of "next steps" for phlogiston, which we won't list here. They are all captured as Phabricator tickets.

The other big outcome (at least for Kevin) was an ongoing/increasing awareness of just how difficult it is going to be to figure out, socialize, and enforce a large set of specific behaviors that people will need to adhere to, in order for the graphs to make sense. We quickly identified this non-exhaustive list of questions related to that topic:

• Should teams track their categories (tranches, milestones) with a separate project for each, or 1 project per team, with categories in project columns?
• Should teams have a separate project per sprint? If so, should they also have all tasks in a master Product backlog project?
• Should teams track status in the Status field or in Project columns?
• Should all teams use points? Should teams that use points allow default values for un-pointed (un-estimated) stories?
• How should we account for cross-team work? Is it big enough to be worth the effort?

Kevin, at least, has probably grossly underestimated this challenge until now. Partly because he was focusing more on a quick-and-dirty solution usable by one or two teams in isolation. Having an org-wide standard is more than an order of magnitude more difficult.

We can see an argument for setting up a weekly burnup meeting, with Terry optional. (UPDATE: Arthur suggests holding off on this for now.)

Kevin would also prefer to vacate the phragile PO role at the end of this quarter.