Sprint Goals
Hi Everyone,
So i need some help currently i run two teams one a front end team and the other backend. Now the backend team is where i am struggling with priorities and sprint goals, our environment is such that its really fast paced so alot of the times we need to jump on items that have not been scoped out with a full technical spec and the devs need to run with these items as these are production issues. Now what is happening is that because our team is really small our SDM (Software development Manager) is using two hats one being a dev and the other the SDM, now alot of the times as these issues are rising they are being added into the sprint adhoc. Its because of this our velocity is dropping and our delivery on features are slowing down. I am in a very tough spot as now the team finds it very hard to call out our boss in terms of the dev work thats being done and without the domain knowledge and without proper scoping the dev team tends to go into this black hole without proper analysis and hence the reason for the drawn out delivery.
Any advice?
Why are you spending a lot of time dealing with production issues? I don't think that it's reasonable to expect no production issues, but they shouldn't be so common that you are frequently needing to stop planned work and address them. I'd recommend investing time to understand the root causes of these production issues and addressing problems in product and process quality to prevent them. Having some ability to craft a Sprint Goal and plan a Sprint that the team can achieve more often than not is key to things like building team morale and a good working relationship with external stakeholders.
Are you allocating time in your Sprint to production issues? Even if you reduce the time spent on production issues, you can use historical data to understand, on average, how much time you're spending in your Sprint to handle these ad-hoc issues that come up. When you craft your Sprint Goal and plan your Sprint, be sure to consider this as one of the factors that impacts capacity, along with effort for refinement and planned time off for the team members and any kind of company overhead activities.
Does having a front-end and a back-end team make sense, from the perspective of having a cross-functional team? By splitting the work in this way, you may be introducing unnecessary handoffs. Handoffs aren't very efficient, especially when the team receiving the handoff doesn't get what they need or expect. There may be ways to organize the teams to improve the overall flow of work, but it may not be as big of a gain as allocating time to finding, fixing, and preventing the production issues that are burying the team.
There are probably other things going on. I'd want to dig into what is meant by "full technical spec", for example, but these seem to be the three biggest things to look at, based on the description you've provided.
currently i run two teams one a front end team and the other backend
- What do you mean by 'running' these teams?
- Do either of these teams possess all of the skills and abilities needed to completely deliver working functionality to the end-user/customer?
- What does your Definition of Done look like?
You mention Sprint Goals, but not much in terms of the Scrum roles, artifacts, and events which would help goal commitments to be agreed and met. Instead you describe other people and goings-on, such as a Software Development Manager, a "boss" of some kind, you running teams, and work somehow being added to a Sprint ad-hoc.
What do you think about having teams run themselves, based on the 3 accountable roles which Scrum describes? Can you envision a self-managing team making its own Sprint Goal commitments, taking the decisions about what to do and when out of the hands of others?