With all your teams working hard on their sprints to deliver the next high priority feature, it’s all too easy to steam ahead in pursuit of velocity, rather than addressing minor questions, potential technical debt or issues that may surface as problems in the future.
Now, no one wants this to derail current momentum or for the team to lose focus, but it’s still important to raise, record and resolve these Bubbles:
What is a bubble?
A bubble is a question or concern that a team or individual would like to raise (“bubble-up”) related to their team’s work. For example:
Will this design scale – the display is already slow with 100 products in development?
Note that a bubble does not need to be raised in relation to existing issues (or be issues at all) – they should just be a relevant question.
Who can raise a bubble?
Anyone – absolutely anyone. It may come from a developer programming the feature, someone performing testing or the Feature Owner themselves, when noticing poor responsiveness.
If there is something that someone needs answering, however trivial, no one should be discouraged from doing so.
When can a bubble be raised?
At any point within a sprint or the wider feature / product development activity. Initially this may be a daily stand-up, perhaps added to the team’s Kanban board at the end of the day or maybe as a new issue in the teams project/issue tracking software (perhaps as a custom issue type in Jira).
How are bubbles resolved?
Very simply, by answering the question (“popping the bubble”) – although this may not happen immediately.
The first port of call should be to their own feature team. Many simpler bubbles can be answered definitively at this level. The team should be able to agree as to whether they can genuinely answer the bubble or whether they are relying on assumptions or speculation. If that’s the case, the issue is simply bubbled-up to the next layer of escalation in their organisation.
With the above example in mind here are some possible answers:
It’s fine, we’ll only have 100 products in the production system and they Feature Owner is happy that the performance meets their acceptance criteria.
Easy – bubble popped! Now consider this answer:
We’re not sure, we plan to have 1000 products. We need to address this. I’ve raised a story to be prioritised at the next refinement meeting.
In this case, there’s an initial answer, but the issue is still present. The answer alone isn’t enough to pop the bubble, but with the story in the backlog that should be enough – it’s going to be addressed or mitigated if there is business value in doing so.
Finally, we have:
I’m sure it’ll be fine when we go to production. The servers there should be faster.
This kind of answer dismisses, rather than pops the bubble. If the team thought they issue needed answering, this should not be accepted. In Setchu, this could be escalated by bubbling up the issue to the Control Set.
Whether you record bubbles formally is largely up to you – but can be useful in larger organisations or longer projects. Additionally, in some organisations (or methodologies) you may find there is already a design authority group that perform a similar function. Using the bubble approach just tries to ensure anyone can provide input and receive a constructive response.
Setchu - Agile at Scale 