Ensure we fully understand what Damon's 'ask' is with burndown charts and from our team in supporting them.
Description
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
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 |
Event Timeline
Comment Actions
@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.