Meeting Notes/2015-12-23 iOS Phlogiston

Josh, Joel A, Max

Josh's goals for Burnup reporting:

1. get the team to commit to stuff covered in a release
2. have weekly iterations where we work through those things
3. estimate those things early on - eg.., we think this will take six iterations.  we will attempt three epics.

Give us a sense of, e.g., normally we burn 20 and we just committed to 30, did we just push back the release date?, or should we cut something?

Things to do to get better data from Phlogiston

Set a default point value

In Phlogiston , set a default point value for unpointed tasks so that bugs don't sneak by as "free" work (I _think_ this won't touch 0-pointed tasks, only nulls).

Close tasks with Status=Resolved.

Many WMF teams use columns to indicate the state of a task, but there is no consistent practice other than using Status=Resolved, so that's the only thing Phlogiston reads. iOS uses columns because many tasks may be done except for approval by Apple, so they aren't truly "Done" for weeks after the developers are otherwise finished, and more work may come back from the Apple review. One solution may be to change the definition of Done for iOS to the point when something is handed off to Apple, or queued up for the next release to Apple, and if more work becomes necessary before the feature is actually released, create new tasks for that work.

Make bugs visible

Point your bugs.

Assign a minimum point value so that bugs don't sneak in as 0-point bugs.

Teams may also use a "bug budget" - this doesn't show up in Phabricator or Phlogiston, but would entail some deliberation on velocity and reserving some velocity for bug fixing. Not clear how/if to represent that in Phlogiston.

Also, look at discrepencies between burnup by count and burnup by points to see where scope may increase on a nominally "closed" area of work. Use iOS Beta growth as example in Phlogiston docs.

Do gross estimation

Put in some gross estimation at the beginning. One way to do this is to do one level of work breakdown from the master task, and then apply high-point estimates (hundred+) to those sub-tasks. Another way is via T-shirt-sizing card sorts:

1. Create high-level tasks at the feature bullet point level (whatever that is for the product or release; perhaps a dozen or less big points for a quarterly release)
2. Break down those tasks where possible
3. Print tasks on index-card-sized paper with removable stickiness (post-its, nametags, etc)
4. Identify some already-completed tasks (3 to 10) that are comparable to the new batch, and put them on cards as well
5. Create a wall grid (where rows are S/M/L/XL, and columns are any dimensionality to get a horizontal spread, such as feature area, technology stack, audience type, etc)
6. In person, with all developers and PO in attendance, put each task up one at a time
   1. Start with the already-completed tasks. get consensus on the row and column for each such task.
   2. For new tasks, add them one at a time. EITHER have consensus for each task, OR one developer could put tasks up, and then other developers could review, flag disagreements, and discuss only the disagreements
   3. Where necessary, break out tasks into smaller tasks on the fly
7. Assign each task a high-level estimated based on the row it ends up in, calibrated by the already-completed tasks.

Possible new tasks for Phlogiston

To be written up as Phabricator tasks.

• some way to capture uncertainty in backlog size
  • project from trend in Backlog size?

• add hyperlinks from Phlogiston to Phabricator where appropriate
  • in project names

• Make a report to show all recently closed tasks with no WorkType tag
• can we get some of the Phlogiston work added to the "easy" list for community volunteers?
• set a default velocity for the team so that forecasts won't fail for work that is estimated but not started
  • At the team level or milestone level?
  • Maybe default to 1 for everybody, to eliminate divide by zero, and then also allow per-team or per-milestone

Next Steps for iOS Team to get more useful data from Phlogiston

1. Set up Milestones
   1. Apply the Milestone tag to Epics that represent Q3 goals and other
   2. Add new categories as rows in https://github.com/wikimedia/phlogiston/blob/master/ios_recategorization.csv
      1. N.B.: can also add columns to master project and add these columns to the github file as milestones
   3. Make sure Joel gets and accepts the Pull Request
2. Do high-level estimation of Milestones (see above - try quick Epics, or t-shirt-sizing card mapping at All-Hands
3. Decide how to solve the issue of closing tasks more consistently and frequently
4. Set a default point value for the team's unpointed bugs in https://github.com/wikimedia/phlogiston/blob/master/ios_source.py