A colleague asked me what to do when you’re in an iteration and you realize that the story you’re working on spawns other requirements. I suggested that the person add them to the product backlog (the backlog of everything you want to do for the product) and re-rank the requirements in preparation for the next iteration. “We can’t do that. Our users won’t let us.” Why not? “Because if they find it in this iteration, they want to add it to the next iteration, if not this iteration.”
The users/product owners/people in charge can certainly add stories to the next iteration–and they will push out what’s on tap for the next iteration. “But they don’t want to. They want us to do all that and all the new stuff.” I asked about their velocity charts and burndown charts. They have no data to explain what’s going on. And, they don’t have cross-functional meetings to re-rank the requirements between iterations. Oh boy.
Here’s what I suspect is what’s going on. The team doesn’t quite finish what they need to do for an iteration. They either have unfinished stories or accumulated technical debt. Maybe both. But instead of adjusting their velocity down, and finishing things for the next iteration, they attempt to do more. Since they can’t finish what they thought they could, they get even less done in the next iteration. And, because they’re not collecting and displaying data, they have no way to explain this to the organization. All the organization can see is that the project isn’t finishing anything.
Even those these folks are using iterations, because they’re not finishing work within an iteration, this project doesn’t look different to the other people in the organization. And they rest of the organization remembers how long it took to finish the last project. No wonder they’re putting pressure on the project team to do more in an iteration–they can’t tell when anything will be done.
I suggested they move to one-week iterations and to finish things within the iteration. Surely there was work they could do in a week. “Yeah, but it won’t be very much.” Bingo! That’s ok, as long as something is complete. Once people can see complete work out of the project team, they have some assurance the team will actually deliver something and can watch for more deliverables. (And, it will help the team estimate better.)
The problem isn’t actually requirements spawning more requirements. The problem is that the project team is not tracking any data that will give them feedback about their work. That data would help other people see what’s going on in the project, but because the data doesn’t exist, the other folks are too scared to trust the project team with any one iteration’s requirements; they want to see all the requirements done.
If you’re trying to move to an agile lifecycle, don’t forget that tracking the data is not just for you and the project team; it’s for the rest of the organization too. You may have a problem with spawning requirements. But you might have a problem where people are assigned to too many projects, so they can’t make progress on yours. Or you might have a problem of not enough automated tests, so the developers are getting feedback too late (outside the iteration) about work they thought was done. Or there’s maintenance work to do. Or people are underestimating what it will take to complete a story. Or any number of other potential problems.
The problem isn’t more requirements; it’s the team’s reaction to more requirements. In this case, they need to be gathering and showing some data. Without the data, people will still push on them to attempt more than what they can do.