Allow work to be added

[gregmac]

As discussed partly in #3 and #1, the rule to disallow new working being added is problematic:

• It's possible "work can be removed but not added" will lead to the unintended consequence of over-filling the sprint. If there are too few items, the development team could end up with nothing to do, whereas if there are too many, they can simply remove the ones they don't get to.
  • From a manager/PO/company point of view: there is a large negative to underestimating (missed productivity) and almost no negative to over-estimating (at worst, the developers complain a bit)
• It's fairly common to come across bugs in existing code while working on the code. Sometimes these are even impediments to the work being done. It should be possible to create a distinct ticket (to make tracking, release notes, etc simpler) and fix the bug, without having to go through the ceremony and delay of putting it in the next sprint.
• Critical in-production bugs can be discovered that are worthy of diverting attention -- customers should not have to wait for up to 8 weeks (end of the following sprint) for a fix.

There could be rules around adding work, such as (not mutually exclusive):

• only developers are allowed to pull in work
• an item of equal size must be removed for any new item to be added (unless everything is done already)
• any added item gets a size inflation penalty (eg, additional points / hours / larger t-shirt size / etc) to account for the context switch it imposes

These could just be suggestions (for team-specific rules), but I think the broader concept of never allowing items to be added is just overall totally impractical.

[davebs]

My opinion is that you should avoid adding work to sprints except in exceptional cases. I address the issue of these exceptional cases with this intentionally vague sentence:

Support work is done on a rotating basis because sometimes things do happen unexpectedly and need to be dealt with, but a surprising number of issues can wait until later.

In my experience, development teams never end up with nothing to do and that's part of the problem.

But certainly do the thing that makes the most sense for you. Product breaking bug in production just discovered? Yeah, maybe fix that first! New feature request? Backlog. So it goes.

[floer32]

@davebs it might be good to clarify or rephrase about support-work. I am all-for your approach of avoiding being over-prescriptive about specific methods. My gut just says the lack of room for support-work would be one of the objections in places where I'd try to implement this (i.e. places that would otherwise be open to all other aspects of it).

I'm fond of Zapier's approach, can summarize or try to make a sentence if you think it's helpful. LMK

[davebs]

Those are good points, how about something like this?

Even though a surprising number of issues can be planned ahead of time, sometimes things do happen unexpectedly. How does this impact the current sprint if it's already been filled with issues? Well, we call these unforeseen and urgent issues "support issues". Different teams will have different requirements for what support means. Perhaps it means to support the customer. Perhaps it means to support other developers. Our approach to this question is basically this: pick members of the team who will have time allocated to Support Issues over the course of the sprint and allocate some amount of time for them to address Support Issues as they come in. For example, "Dave is estimating 16 hours of support work in this sprint." Support Issues are left undefined at the sprint's outset. As they appear and become defined, they can be routed to the most appropriate team member that has a block of Support Issue work allocated for the sprint.

Maybe take a stab at an alternate if you see something that needs clarification or doesn't make sense. Or if you can see a way to make it shorter, it's rather verbose.

Also, I like the idea of everyone touching support. Particularly in the environment of new product development, it's a great way for everyone working on the product to understand the customer better.

[floer32]

@davebs Here’s a quick riff on that:

Most sprint work can be planned, but sometimes things do happen unexpectedly.

One approach: try support rotations. Some member(s) of the team will allocate time for unplannable Support Issues. These have estimates like other issues, the only difference is the ambiguous or undefined requirement.

Different teams will have different requirements for what support means. Perhaps it means to support the customer/clients. Perhaps it means to support other developers. - rotating everyone through customer support is a great way for everyone to understand the product and clients better.

[👆 maybe there is an inline link to Zapier’s writings, in that sentence.]

It may be good to track the time you dedicate to undefined work, as variations in it can be leading indicators of chronic problems and risks.

[Wojciechem]

Rotational support sounds like a good idea, but in practice I've seen programmers loathe it. Ad-hoc type of work that support is, differs much from organized sprint work.

There are good arguments for rot. support like everyone learning your product / users, sharing knowledge etc. On the other hand, support is mostly handling defects or odd behaviours if system, not the correct app flow.

For me support is a specialized work, and pushing it to the people working in a sprint can be a serious cause of burnout. Think of the SLA-induced stress, interruptions and re-learning of the same knowledge, picking up work after different colleagues etc.

[davebs]

https://github.com/davebs/AgileLite/commit/fa10e65af384ce3a1ea0a9edfe4ecfba1eef3c48

Thanks everyone, I made some changes, open for input.