I’m working on my third iteration right now, focusing on server-side functionality. The current iteration is called “Backend Processing and Data Integration”. I have several user stories related to this work - some are done, others are still in progress.
During a demo to our stakeholder, they gave me extensive feedback about the user interface. This feedback is important but completely different from my current backend tasks. I felt I should pause my server work to fix these UI problems before they spread to other parts of the system.
The issue is that JIRA doesn’t let you pause an iteration and start a new one. You have to complete it first. Adding UI tasks to my current backend-focused iteration feels wrong since the iteration name suggests it’s only about server-side work.
What’s the right approach here? Should iteration names be more generic so mixing frontend and backend work isn’t weird? Or should I handle this situation differently in Scrum methodology?
Depends on how urgent the UI feedback is. Stakeholder concerns during demos usually mean there’s real usability problems that’ll get worse if you ignore them. But you don’t need to blow up your whole backend sprint either. I’d check if these UI issues will actually mess with your remaining backend work. Sometimes UI problems expose deeper architectural issues that hit both layers - if that’s happening, fix it now and save yourself headaches later. For next time, build in a small buffer for demo feedback - maybe 10-15% of sprint capacity for unexpected critical stuff. That way you can tackle urgent feedback without ditching your planned work. Don’t let the sprint name drive your decisions. Focus on what gives users the most value and keeps technical debt under control.
just throw those ui tasks in your sprint. the name doesn’t matter - it’s all about delivering value. you need stakeholder feedback asap, and waiting will only create bigger headaches later. if the sprint name bothers you, call it “backend + ui fixes” or whatever works.
I’ve hit this exact situation tons of times. Demo feedback always uncovers stuff you missed during development, so you’re smart to worry about fixing it fast. Don’t let the iteration name box you in - that’s just admin nonsense. What actually matters is whether your team has the bandwidth. If you can squeeze in the UI work without screwing up your backend deliverables, just do it this sprint. But if the UI changes are huge and would tank your backend goals, push back. Talk to your product owner about moving some backend stories to next sprint. On the JIRA thing - most places I’ve worked treat sprints as locked timeboxes. You don’t pause them. The trick is keeping your sprint goals flexible while sticking to the timeline. Going forward, name your sprints by dates instead of features. Saves you this headache completely.