This is a proposal for a new bug management system for SumInpUp. The new system is code named Edwin.
Sprints are modelling a process that doesn't really work. Every two weeks we get together and decide what we are going to do in the next two weeks. And sometimes we plan rough sprints more than two weeks in advance, even as far as planning out sprints for the entire next quarter. Sprints are supposed to give us a sense of time for when implementation will be done. But in all of Q1, only one sprint got everything done, so these "completed by" dates are weak at best. When a bug crosses the boundary between two sprins, like when it is started in one sprint but finished after that sprint ends, the system breaks down. Ideally this wouldn't happen, but in practice it happens all the time.
The goal of this proposal is to give stronger time estimates, while at the same time allowing bugs to naturally develop on their own time frame, instead of being boxed into sprints. Long term planning should be possible, but short term agility is the focus.
This system is not intended to store any state. Bugzilla and GitHub will be the source of truth for all data. Any data that can't be derived from one of these sources probably won't be included in Edwin. We may add a caching layer, if it becomes needed, but the original design does not include this.
This is the primary interface of Edwin.
NB: Columns shown and layout are preliminary, and limited by ASCII box art
+--------------------------------------------------------------+
| |
| <SumInpUp> |
| |
| ID Summary Pt Status |
| 1145117 Django 1.6.11 Upgrade 1 Merged [===== ] |
| 1143941 Localization top contributors 2 PR-2430 [==== ] |
| 1143945 Date range selection UI 3 PR-2430 [==== ] |
| 1131143 I'd like to be able to see... 2 ASSIGN [== ] |
| ------------------------------------------------- 2015-04-07 |
| 1087676 Ability to pin articles at... 2 NEW [= ] |
| . |
| . |
| . |
| ------------------------------------------------- 2015-04-14 |
| |
| |
| <Ready> |
| 1143945 Date range selection UI 3 NEW |
| |
| <Needs Prep> |
| 1343945 Date range selection UI - UNCON |
| |
+--------------------------------------------------------------+
The 3 primary sections of the forecast are the Queue, the Ready area, and the Needs Preparation area.
Bugs that have been identified as important to work on will show up here. Likely this means that someone has added some sort of flag to the bug. "Needs prep" is defined as having blocker bugs that aren't in the Queue or not having full esimation metadata (u=, c=, p=). If non-trivial work needs done before a bug is shovel ready, it should be a bug that blocks another bug.
Bugs that have been flagged as important to work on, and have no remaining prep work, will be automatically shown here. This area represents work that needs prioritized. Bugs here should be "shovel ready" (which should be a result of being flagged to work on, having full estimation metadata, and no blockers).
People can take bugs from this area and insert them into the queue.
Bugs here are ready to work, and are presented in a manually sorted list. Bugs can be dragged up and down to change sort order. Developers should work on bugs from the top to the bottom. When a bug is done it should be marked Resolved. When this happens the bug will be hidden from view. A separate view may be available to view finished bugs.
Bugs here have a progress bar that represents the steps a bug goes through in its lifetime. The steps are roughly "Prepared", "Assigned", "In Review", "Merged", and "Resolved".
The queue will try and estimate the time each bug will take until it completed. Instead of showing these estimated completion times, each bug will be grouped into a "cohort" that will get a line below it with a date. Each cohort will be about a week long. Hopefully the estimated time for each bug will take into accout its progress.
For example, if the top of the queue contains 15 bugs, each estimated as 2 points, and Edwin has been configured to expect the equivalent of 2 developers working full time on the bugs, it would estimate that the first cohort break point would be after 5 bugs (10 points) and so it would draw a line underneath the 5th bug labelled with a date one week from now. Another similar line will be drawn under the 10th bug with a date 2 weeks out, and a 3rd line after the 15th bug labelled 3 weeks from now.
These lines will be predictors. Hopefully they will be accurate, but they are not deadlines. If we find that the predictors are often inaccurate, it may be that the algorithm needs tweaking, or that we have persistent problem with our estimates.
Sorting is hard, especially if we want to treat Bugzilla as the source of truth. For this, I propse we construct a sort of linked list out of bugs using comment tags. We can tag the first comment as a bug as "edwin-after-12345" which would put the bug in the queue after 12345. If 12345 isn't in the list, then this bug would be at the top of the list (presumably because 12345 has been finished).
Comment tags don't send emails, are totally freeform, and we can do prefix searches on them. The book keeping of making these comments should be entirely handled by Edwin.
The name Edwin comes from Edwin Jarvis, the butler of the Stark family in the Iron Man mythos, and the namesake for JARVIS, the AI that manages Tony Stark/Iron Man's work. Additionally, it superficially fits the naming scheme of many of our other tools.