Team consistently not making sprints
So I know that this question has been asked before, but since I haven't really seen anything that benefited my problem, I thought I would give it a chance.
So first things first, in a perfect world we would be completing sprints and at the end of every sprint, we will deliver all the story points that we have committed to. I know that it is not always attainable, so a 90% delivery to me is still acceptable.
The problem I am facing at the moment, is that we commit to (For arguments sake) 100 story points, but only complete 20. This becomes a nightmare as trying to manage the client becomes almost impossible. Now the logical thing to say here is that we are over committing each sprint or underestimating stories which is very possible.
Just to explain the process, maybe I am missing something,
- We have 2 week sprints
- During sprint, product team gets requests from the client and do requirements gathering, running details past the team/tech lead prior to prioritizing the backlog (We don't have a dedicated grooming session, however stories are fleshed out properly prior planning 1)
- Thursdays of every second week, we do planning 1. This session is run by the product team, we try to estimate as much of the stories on the backlog as possible, backlog is ordered based on the current priority.
- Fridays of every second week, we do planning 2. This session is run by the Team lead, expectation is that the team took some time between session 1 and 2 to go through work required in order to adjust estimations, but we go into more technical detail of the change required
- Planning 1 is for initial estimations, this can change during the planning 2 session
- The team is left for 2 weeks, there are cases where scope creep occurs, however try to limit it as much as possible as we have a dedicated Developer to work on production issues that is not part of sprint work
The problems I am facing are the following,
- Team does not communicate that they will not make sprint deadlines
- Team seems to not fully understand the features that are requested (Could speak to lack in requirements, however I don't fully think so)
- Team takes too long to develop features, going over the expected delivery estimation.
- Team does not take the initiative to go through future stories during the gap between planning 1 and 2
I know that this is a very common issue in software development, however it is an extremely frustrating one as you struggle to build confidence with your client if you cannot deliver on time. Just to give context on myself, as that might have a direct influence. I am currently the SDM for multiple teams, due to a bit of a lack of technical understanding (Team/Tech lead) in some teams, I am quite involved with some planning sessions. I come from a senior developer background, have been developing software for about 10 years.
Team in question, can differ in size, but 10 Developers, 3 QA, 2 Product, 2 Team Leads.
Sorry if this is a duplicate question, I have checked the other questions and answers and thought it made more sense to post a new question.
The purpose of Sprints is not to deliver points, but rather to deliver value. The team doesn't commit to delivering a certain set of points or a set of Product Backlog Items. Instead, the team forecasts how much work they can accomplish as part of Sprint Planning. Throughout the Sprint, the team should be focusing on achieving the Sprint Goal, rather than completing a particular body of work or finishing so many points or some other measure of output.
Looking at the specific practices, I can see several potential problems or opportunities for improvement.
Your refinement process seems lacking. Recent revisions of the Scrum Guide suggest that about 10% of the Development Team's capacity should be allocated for Product Backlog Refinement. If you have a Development Team of 3 people and a standard 40-hour workweek, I would expect about 12 hours per week allocated to refinement. There's no defined method for performing refinement. Some of the teams I've worked with had everyone get together a few times a week. Others had people work individually on refinement and then get together for about an hour or so a week to align. The team needs to figure out what works for them, but it is important that it is a full-team activity to get the knowledge spread out and get the whole team to buy-in to the work being done.
I believe that the poor refinement is leading to a number of the problems described, including not fully understanding the features they are being asked to built and taking too long to develop the features. It's highly likely that the lack of understanding is leading to longer development times.
The "Planning 1" and "Planning 2" is not clear to me. Sprint Planning is a single session. There are two aspects to it - the first is determining what to build based on forecasting and the second aspect is determining how to build it. More specifically, the primary outcomes for the first part of Sprint Planning is a Sprint Goal and the outcome for the second part is a plan to achieve that Sprint Goal.
The team size and composition may also be issues.
Although Scrum doesn't enforce rules on a minimum or maximum team size, Scrum is most effective with a Development Team size of between 3 and 9. You have 13, maybe 15 (depending on if the Team Leads are part of the Development Team). That feels very large and communication gets difficult with that many people.
I'd also point out that Scrum doesn't recognize a "team lead". Such a concept tends to lead to work being pushed onto the people doing the work rather than being pulled into a Sprint and then into development. It also doesn't promote self-organizing teams.
There's no mention of the Daily Scrum or the Sprint Retrospective, but I'd suspect two things. First, with such a large team, you aren't able to effectively hold a Daily Scrum in a reasonable timebox. Second, many of these issues may come out in a well-run Sprint Retrospective.
The biggest issue that I see is poor communication. The team size and lack of constant collaboration are probably the two biggest drivers.