Applying Scrum to a Template-Based Product Backlog: Handling Frequent UI/UX Updates
"Hi everyone,
I am currently working on a project called Funnelsflex, where we develop high-performance sales funnel templates. As our library of templates grows, we are finding it challenging to manage the Product Backlog effectively using Scrum.
Specifically, we face a lot of 'Emergent Work' due to frequent UI/UX browser updates and changing marketing automation APIs. My question to the community is:
How do you manage a Sprint when a significant portion of the work is 'Refinement' of existing templates versus building new features? Does anyone have experience using Scrum in a high-volume digital asset or marketing template environment?
I'm looking for advice on how to keep the Sprint Goal focused when maintenance of previous templates starts to compete with new development.
Looking forward to your insights!
Best regards."
It's not clear to me what the problem is.
Is this "emergent work" to "refine" the existing templates critical and interrupting the planned work? If so, is there any reason why it can't go on the Product Backlog and be ordered for a future Sprint instead?
If the work isn't interrupting the team, I'm not sure why the Sprint Goal isn't a focusing tool for the team. If so, I'd like to understand what can be done to minimize those interruptions. That could mean identifying the work before it becomes critical, so it can be planned rather than interrupting the team. Or it could mean restructuring the work. But knowing the types of work the team faces and the impediments to planning a Sprint can start those conversations.
I'm looking for advice on how to keep the Sprint Goal focused when maintenance of previous templates starts to compete with new development.
That's all parcel of real-world complexity. It isn't even consistently complex. Hence support and maintenance work may predominate in one Sprint and new development in another. Sprint Goals may reflect this:
- A Sprint Goal for support and maintenance might be based on flow, such as a rate of throughput, or limits around work-item aging so service level expectations can be framed and met.
- New development work may have a Sprint Goal which involves the provisioning of a feature.
A good Scrum Team might switch from having a flow based Sprint Goal one Sprint to perhaps a feature based one the next.
The ideas shared above are good, and they made me wonder a bit.
In IT environments, this situation often resembles escaped defects returning to the team. Instead of progressing with new features, the team is pulled back into fixing previously delivered work.
This is typically a Retrospective discussion: how do we move from reactive firefighting to a more proactive approach? The team can explore patterns for example here a few:
- What is causing the recurring issues?
- Are certain categories appearing more frequently? (Try identify the 20% that cause the 80% of issues.)
- Are template requirements or descriptions unclear?
- Are there misinterpretation or errors creeping in during implementation?
The goal is to identify root causes for the reword that can be eliminated to reduce the amount of rework.
This transition is not immediate. For a period, the team may need to balance fixes with new development. However, if root causes are addressed systematically, maintenance pressure should decrease, allowing greater focus on new features.
With the above in Scum terminology, the Definition of Done might not be complete. Work are not delivered in a done state.