Hey guys,
I am a new Scrum Master for a Digital Technology team of Developers and QA. I’ve been there close to a month. My team Is new to the Scrum process. The challenge that I’m having is the backlog is massive and the PO is so busy and hasn’t had time to groom it, so everyday we’re pulling items from the backlog, and items aren’t put in for the next sprint. Therefore as a new SM, it can be challenging , and it’s also confusing and challenging to the Dev and QA team. Plus they are burned out because they’re working in 1 week sprints(hopefully I can change this as a project is needing next month).
These are the issues that I have identified. I have done 1 on 1’s my first week to introduce myself and get to know each person, as well as they’re roles they play. The next week, I created a deck about Scrum. My 2 constraints is getting the backlog refined. Next, is the team experiencing burnout.
This is a loaded post, but wondering if anyone have any suggestions.
Thanks in advance
I guess I’d suggest that you need to stop looking for solutions to push onto your team in your context, and start making the problems highly visible to the team.
When they can see the problems, as a team, you can start to experiment on potential solutions. And that’s what we want – teams that experiment and solve their own problems, not “heroic” Scrum-Masters-As-Consultants addressing the surface symptoms.
Using a good Kanban method board is maybe one starting point for this.
– get the team together and map the value stream you have, from an idea right the way through to completed, deployed software in the hands of the users
– identify every stage gate, hand-off, discussion point and so on.
– build this into a Kanban board; look at the Kanban Method for ways to do this. Each stage needs it’s own column. Each column should be split into “Doing” and “Done”; if you prefer you can split into “waiting to be worked on” and “being worked on”
– when work is stuck because someone is doing something else, then block that work
Then you can start to look at why the team is burning out…..
In terms of one-week Sprints….
The Sprint Cadence is a wrapper for when you want to explore product-market fit with stakeholder and customers. One question might be “should we end-of-life this product now?” for example. A week seems a very short cycle to be able to obtain meaningful business intelligence about the evolution of the market, customers, technology, legal frameworks, what your competition is doing and therefore how you need to inspect and adapt.
So – sure, potentially longer Sprints are an experiment you could run, but I’d tend to make the work visible first, and focus on why everyone is so busy and yet stuff is not being completed…