|
|
= Release Planning =
|
|
|
|
|
|
== Goals ==
|
|
|
|
|
|
* Not have too much stuff left over at the end of a release
|
|
|
* Plan more accurately
|
|
|
* Do higher-priority things first
|
|
|
* Make the process easy to understand and implement
|
|
|
|
|
|
* What should we do with 0.3.5, 0.4.0, and 0.4.1 milestones?
|
|
|
|
|
|
=== Personal Goals ===
|
|
|
|
|
|
* I want clear priorities
|
|
|
* I want a very clear indication of which task is next
|
|
|
* I want to know how much time I should spend on a task
|
|
|
* I want limits on the amount of tasks I can have in progress
|
|
|
* I want to know when I should stop and ask for help
|
|
|
* I want to feel like I am making progress every day
|
|
|
|
|
|
* I want to spend less time on tasks that drag and I don't feel like I am making progress
|
|
|
* I want to know what I should do when a task blows up into something much larger
|
|
|
* I don't know if I am expected to read all the IRC backlog
|
|
|
* I often hate how much time I spend on email
|
|
|
* I sometimes hate how much time I spend on various administrative tasks
|
|
|
* I want meetings to be very short and focused on the essential things that we all need to do
|
|
|
|
|
|
== Discussion ==
|
|
|
|
|
|
Roadmaps tell us which tickets belong in which releases.
|
|
|
|
|
|
=== What are we bad at? ===
|
|
|
|
|
|
* Capacity Estimation
|
|
|
* Task Estimation
|
|
|
* Roadmapping
|
|
|
* Post-Roadmap Extra Tickets
|
|
|
* We don't have a concept of a full release
|
|
|
* Points in a release, and points left over
|
|
|
* Bugfix points: an estimate for unplanned fixes and their size
|
|
|
|
|
|
=== What could we possibly do? ===
|
|
|
|
|
|
* Proposal: marking things for a milestone is good
|
|
|
* Proposal: putting tickets in a milestone after a capacity check is a good idea
|
|
|
* Proposal: one person checks capacity, and we should try to automate that check
|
|
|
* Proposal: when a milestone or sponsor is full, we stop adding tickets
|
|
|
* Proposal: regressions and security tickets go into the milestone
|
|
|
* Proposal: put really important must-do tickets in the release milestone
|
|
|
* Proposal: we allocate time for unspecified bugfixes and urgent things, and we reduce that time when we add a ticket
|
|
|
* make a ticket with that time, and make it smaller when we spend the time
|
|
|
* create a few buckets of time:
|
|
|
* routine work
|
|
|
* urgent work
|
|
|
* technical debt reduction
|
|
|
* Proposal: tag nice-to-have tickets and put them in unspecified
|
|
|
* Proposal: track story points and velocity, rather than days of time
|
|
|
* reference stories, to anchor estimates
|
|
|
* Proposal: order tasks by priority, and do the high-priority tasks first, with a time limit
|
|
|
|
|
|
=== What should we do in the next few weeks? ===
|
|
|
|
|
|
* We need to deal with 0.3.5 and 0.4.0
|
|
|
* Proposal: dump all 0.3.5 feature tickets in unspecified
|
|
|
* Proposal: dump all 0.4.0 feature tickets in unspecified
|
|
|
* Proposal: triage 0.3.5 and 0.4.0 bugs
|
|
|
* We need to create 0.4.1
|
|
|
* Make the roadmap good
|
|
|
* Proposal: under-promise and over-deliver
|
|
|
* Proposal: work out our staff capacity for 0.4.1 in each month:
|
|
|
* 238 person-coding days in 0.4.1
|
|
|
* 72 person-coding days for February
|
|
|
* 72 person-coding days for March
|
|
|
* 63 person-coding days for April
|
|
|
* 31 person-coding days for May
|
|
|
* Proposal: work out the sponsor deadlines, and put sponsored work before the deadline
|
|
|
* sbws finishes at the end of March, and has 18 person-coding days
|
|
|
* Sponsor V finishes in September, and has 24 person-coding days
|
|
|
* Sponsor 19 finishes in May, and has ??? person-coding days
|
|
|
* Sponsor 31 finishes in November, and has 110 person-coding days
|
|
|
* Sponsor 2 finishes in August, and has 42 person-coding days
|
|
|
* Proposal: remove everything from 0.4.1 that isn't on the roadmap
|
|
|
* Proposal: add tickets to 0.4.1 based on the roadmap
|
|
|
* Proposal: add time to 0.4.1 for unexpected bugfixes etc. |