firefox development process changes
gavin at gavinsharp.com
Thu Aug 7 18:55:36 UTC 2014
Answering quickly, bullet-style.
> Do I need to resolve *all* committed work before picking up anything else?
No - you just need to have the committed work be far enough along that
you have a high degree of confidence that it will be completed in the
iteration. We loosely track this state as the "in review" or
"resolved" in the spreadsheet.
> What is the aim of this cap?
I mentioned this briefly, but the primary goal is reducing "carry
over" - that is, making sure that the work we commit to at the start
of the iteration is the work that gets completed by the end of it.
We've been regularly completing 50% or less of the selected work (see
the "close rate" stats in the historical performance reports at
in a given iteration, which means that while we have a fairly high
degree of confidence in "how much" we'll be able to get done, we have
very little idea "which part" of the selected work will be completed.
That makes planning difficult, and also makes it hard to isolate the
real blockers to productivity (because of the confounding "we just
picked too much" factor).
> How much of the carryover from the iteration reports is really "new work" picked up late in an iteration?
Marco can provide more detail here than I can, but this was a theory
we investigated when determining what to do about carryover, and my
recollection is that "late additions" represented only a small part of
the carryover we were seeing (and definitely there were many examples
of work being picked in a planning meeting and then being carried over
> if you look at the commitments from this week's meeting, the early meeting picked up 70% of the cap. Why is that?
Simple answer: the early meeting is a larger group, and represents a
significantly bigger portion of the team in terms of person-power. It
doesn't quite line up perfectly, and there will always be some
imbalances (we are not enforcing that the person ratio match the point
ratio exactly, or that all engineers are capped at the average points
per-engineer number), but it's expected that the larger group will
pick up a larger portion of the work.
> I like to have several bugs "on the go" simultaneously. [...] This doesn't jive with the cap, because now I can't pick up more work
The cap shouldn't prevent you from picking up more work if you
otherwise have nothing else to do. If all of your committed work is
blocked on others, and you are not able to unblock it through your own
efforts (expending time/discussion shifting review requests, or poking
people, or making requests to me or others), then you can pick more
work regardless of the cap. If other people are running into issues
preventing them from completing their committed work, then it might be
a good idea to look there before picking up new work (and the
leadership team can help coordinate such "re-balancing" efforts). We
are also trusting you to use your own judgement here, and not commit
to additional work if it puts your original commitment at risk.
Holler if any of that needs elaboration or clarification!
On Thu, Aug 7, 2014 at 9:43 AM, Gijs Kruitbosch
<gijskruitbosch at gmail.com> wrote:
> In response to this, I had some questions, which I was encouraged to raise
> more publicly, which I am doing herewith:
> On 30/07/2014 00:41, Gavin Sharp wrote:
>> we're going to cap the size of the selected work based on historical team
>> performance. The cap is a rolling cap that will adjust dynamically as team
>> performance changes over time. This work will be the team's commitment. If
>> committed work is complete, the team is free to pick up more work at your
>> discretion, but not at the cost of committed work.
> What does this mean in terms of picking up new work mid-iteration? Do I need
> to resolve *all* committed work before picking up anything else?
> What is the aim of this cap?
> Assuming the aim is avoiding people picking up work and that causing
> original (prioritized) commitment from being carried over and remaining
> How much of the carryover from the iteration reports is really "new work"
> picked up late in an iteration? (looking at the spreadsheets, both work that
> I picked up at the start of the iteration and work that I picked up on the
> last day gets marked as "Carry over" for the next iteration, which I find
> More practically, if you look at the commitments from this week's meeting,
> the early meeting picked up 70% of the cap. Why is that?
> Finally, I often run into the fact that I am blocked "mid-bug" on a
> needinfo, review, dep/blocking bug, UX decision, ... etc. This is one reason
> that I like to have several bugs "on the go" simultaneously, because then
> instead of twiddling my thumbs I have alternative stuff to work on. This
> doesn't jive with the cap, because now I can't pick up more work. It was
> suggested that instead of picking up other stuff, I should make (more) noise
> when I'm blocked so that GMC/management can help get things unblocked ASAP.
> This raises two concerns:
> - I'm worried this won't scale;
> - Personally, I am hesitant to "complain" to folks "higher up" that I'm
> blocked because I'm waiting on one of my colleagues (who are often busy
> enough without being chased about their needinfo/review requests).
> ~ Gijs
> firefox-dev mailing list
> firefox-dev at mozilla.org
More information about the firefox-dev