We have a velocity of zero
morde last edited by
I am a Scrum Master for a small development team of 7 developers and 3 testers with 2 week sprints.
The product we are working on is large with a lot of modules. The breakdown of the modules is fairly clean conceptually but their is a lot of interaction between the different modules. And their is a combinatorial explosion in the way they can be used such that it can be a challenge to test all the possible paths through the product.
At the planning meeting we re-estimate tasks left from the old sprint and the developers re-estimate most of them as zero effort as they are "in review" or "in testing". At the end of the sprint most of the stories in the done column have an estimate of zero story points and those that don't have factions of a point.
There are several problems. The team has the habit of under-estimating stories and over-committing in the sprint. The stories snowball as they go through the process. And many team members have other responsibilities and can be pulled off the team at any time during the sprint in a way that is hard to predict. There is also too much work in progress. I have tried banning zero story point estimates but received a rather negative reaction from the team when I suggested this. I have pointed out that review and testing is also work and requires effort for the team but there is resistance to this concept.
I have been pushing for smaller stories and lower commitment over the last few sprints, with some improvement and we have reduced work in progress but we have a long way to go.
With the snowballing effect, a lot more work is usually uncovered in the discovery phase. In review the reviewers have suggestions that sometimes have something to do with the story and sometimes not. In testing the testers find bugs that sometimes have something to do with the story and sometimes not. And everything is added to the old story rather than opening a new one.
I am sure what we are doing is some kind of anti-pattern. I have found reading through PMSEs questions with the scrum tag very helpful, but not all of my questions have been answered by reading though the backlog. So I have jotted down my thoughts in hopes of obtaining some inspiration.
The first step is to get any estimation to include the whole team. Rather than just the developers estimating development effort, the estimate should consist of the effort and complexity from the entire team needed to get it finished and through testing successfully. If you couple this with not reestimating and not getting any credit until the work is done, you can also reduce the snowballing. I'd want to understand why the team has an adverse reaction to some of these ideas already proposed and address those.
Improving refinement can also help. I'm not entirely sure what you mean by the "discovery phase", but it seems like teams are pulling work into the Sprint that hasn't been well-refined. If something is critical and time-sensitive, it may make sense to start it before it's well-refined. The majority of the work should be well-refined and estimated going into Sprint Planning so the team has a good idea of the scope and effort necessary to get it to complete.
A good Definition of Done can help with both estimation and planning. This is a way to ensure the team has an understanding of what state each unit of work, as well as the system as a whole, is supposed to be in at the end of the Sprint.
Test automation would also help significantly, especially in complex systems. Having automated unit, integration, and system tests can help find issues early if they are integrated into the build process. It can also shift your manual testers from always running regression testing into exploratory testing and usability testing, which require human thought and outside knowledge and experiences.
I'd want to learn about why team members are being pulled off the team during a Sprint. This makes any kind of empirical decision making extremely difficult. One of the core values of Scrum is focus - the team needs to be able to focus on the work and the team goals. This also aligns with the Agile Software Development principle of building work around teams of motivated individuals - teams usually don't have people coming and going in the middle of a game.
It seems like the biggest problem here is the team's inability to try something new and to experiment. I'd want to dig deeper into the "that's not the way we do it here" approach. I'm wondering if there's not some more fundamental trust or safety concerns on the team. The team needs to be in an environment that favors continuous experimentation in the name of continuous improvement. Not all experiments may be an improvement, but that's the advantage of rapid iterations - you are making rapid changes to the product to get feedback, but you can also make rapid changes to the way you make the product to get feedback about how you're building the product.