We have a velocity of zero

Question

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.

Answer 1

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.

Answer 2

There are so many things happening here that if you try to enumerate them, you'll just get frustrated, as I suspect you already are.

Let's start with a simple acknowledgement that your team is not, in any way, practicing Scrum. They may be doing great work, but they aren't even trying to use the Scrum Framework. This isn't meant as a judgement on the team, but you need to know where you're at right now.

The next question is: what do you actually want to do as a team? Do you just have a fixed set of work you're going through and you want to go through it smoothly? If so, set Scrum aside and maybe use some Kanban to smooth out your process. On the other hand, if you're looking to release small shippable increments of usable product (and by you, I mean the whole team), then maybe start with that - at the end of each sprint, we ship something, even if that just means promoting to a staging environment that stakeholders can try out. A Definition of Done will be helpful to determine what potentially shippable means, but if you have some other way to measure it, that's fine. I would start here. Opportunities to introduce the rest of the practices will come as the need for them arises.

Answer 3

Sounds to me like your team wants to work, but doesn't want to solve, to plan or to be held accountable. Fairly common in my experience, generally a reaction to the presumption that management will hold the team accountable for negative outcomes, but not for positive outcomes.

. . . [there] 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.

I'm not an initiate of the scrum religion, but my understanding is that one of the assumptions is that the software isn't done till it is tested, and the team is on the hook until it is done. Throwing modules over the fence to testing seems to be in tension with scrum principles. If they are in review, or in testing, that is work that needs to be done; a cross functional self organizing team ought to re-organize to do that work, and ought to estimate that work.

I speculate that the fundamental disconnect is that the team is organized defensively around the goal of avoiding management attention; I think the goal of scrum is for the team to self-organize around the goal of shipping software and satisfying customers.

At least in my experience, the team's perception of reality is more accurate that the scrum goal. Management is - in my experience - very unlikely to recognize and support self-organizing teams, and is much more likely to encourage/facilitate/support traditional management culture, so the team is probably behaving rationally in the context of their management. (I could be wrong; only you and your team know whether your management/rewards structure are scrum based or traditional).

So what would I do in your shoes?

1. Transition the team to scrumbut - recognize that the organization wants traditional management with scrum vocabulary.

2. Discuss with the team the future of their course of action. Continuing to estimate zero complexity will eventually result in shipping zero product and that will result in salaries of zero dollars. Estimating isn't an exercise in avoiding punishment, it is an investment in work. Either you estimate honestly, or you accept that you'll be working to the (unstated, uninformed) estimate of the boss with the pointiest hair, the loudest ego and the least commitment to reality.

3. Discuss with the team the value of project management. In my experience, techs want to work on the project. They don't want to go to meetings, answer questions about due dates, or deal with requirements that change like quantum foam. A small investment by the team in honest estimating will result in an informed PM who can take over management communications. A PM who can broker between management's need to plan and estimate and the team's need to work on the actual complexity of solving problems can be a boon to both sides.

4. That frees you up to work on the real issue - who is accountable for testing & quality control? There are ways to move that into the team - variations of test driven development & automated test frameworks.

Answer 4

Don't re-estimate the story points which have fallen out of the previous sprint, you're telling the team their commitment and points are not important and undermining the process. You need to get to the bottom of why. When you introduce this rule the team may say all the work is done which should lead to a conversation as to why the tasks were not fully complete. Potential reasons could be...

• The story was passed to QA last minute, this can be remedied by reducing your velocity and monitoring the effects. You also need makes sure there is content flow of work to the QAs
• The team may say an external or internal issue is slowing them down or blocking them, You need to remove this issue or worst case scenario allows stories to be closed whilst devising a solution (there will be debt incurred)
  • Use your retros to figure out what's going on

Estimation - I've assumed your using points as opposed to time, if so make sure you play pointing poker and adhered to simple rules that everyone points at exactly the same time, this will help you identify discrepancies in the stories, whos not paying attention, Ambiguity, when someone say 3 and another says 21 you know something is up. Using complexity will also ensure that the team is not committed to time they are committed as a team to velocity which makes them less vulnerable.

Reviews - Anything that was not in the original story should be added to the backlog and prioritised, you shouldn't simply leave the story open.

Snowballing effect - This is probably a mixture of unknown, unknowns and other factors such as better refined stories, All things you need to explore in your retro. Expect your project to increase in size given the complexity, makes sure all new work is prioritised and work on what important to the product owner.

Answer 5

With a highly interdependent system such as you describe, "stories" might not be sufficient either as a measuring tool or a task-layout tool. You need to incorporate an understanding ... no doubt provided by the experts in the team itself ... of how "stories" actually relate to the components of the underlying system. Because, "this is where the workers are actually working, and what they are actually working on, in order to bring the 'story' about." Ask them to identify which parts of the system are going to be impacted by (the various elements of ...) each "story," and use this to drive both the task-breakdown structure and your reporting of it.

Because, let's face it ... "software is a rat's nest of dependencies." And the structure of the system doesn't always map as neatly to (say ...) "user stories" as The Scrum Guide preaches that it "should." Okay then, find what works for this system. Stories might need to be decomposed, then mapped to interdependencies within the system, then re-ordered in some way to reflect how the interdependencies depend on(!) one another, in order to finally arrive at something that you can schedule and therefore manage. What you don't want to have happen ... and which right now just might be happening ... is, "do it yourself." Where the breakdown that I just described does happen, but not formally.

Leverage the team's members heavily to guide this idea: they know the system best. They are the SME's here. And show them that, if they work with you on this idea, everybody's work and workload will become better. (And certainly, yours too!)