Ensure we fully understand what Damon's 'ask' is with burndown charts and from our team in supporting them.
|Resolved||ggellerman||T88365 Burndown chart training and support - VE release support with Editing Team|
|Invalid||KLans_WMF||T88328 Setup burndown functionality for App projects|
|Resolved||Awjrichards||T88325 Whole team chat with Damon RE burndown chart expectations|
|Resolved||KLans_WMF||T89030 Spike: Current state of burndown in Phab|
@Aklapper yeah this has indeed happened.
Here's a high-level summary from my notes of what came out of our talk:
- The important thing is to know how fast we'e coming up with tasks (bugs, new features, etc) and how fast we are closing them; have a visual way of making progress, driving the burndown line DOWN
- When Damon says 'bugs' he doesn't necessarily mean 'defects' - he means any ticket in the system (could be a defect [like, an actual bug], a new feature, user story, etc)
- All engineering teams should be using burndown charts, though we should focus our efforts on who we support in implementing the basic things needed for meaningful burndown charts: backlog, triaging, and estimation
- It's ideal to have burndown charts in a location as close to where work gets defined and discussed (eg in Phabricator), though this is not necessary
- Not all teams need to necessarily have their charts in the same place
- KEEP IT SIMPLE - we don't necessarily need to go deep into the kinds of 'hurricane charts' Damon was demoing at MWDS; we can start with something simple and basic so long as it communicates scope and progress.