wiki:org/meetings/2019BrusselsNetworkTeam/Notes/ReleasePlanning

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.
Last modified 2 weeks ago Last modified on Feb 1, 2019, 12:08:58 PM