It can be tricky for managers and technical leaders to make the transition to agile. They’re likely accustomed to doing things a particular way. What’s more, they may try to squeeze their old ways into the new, agile approach. Here, Johanna Rothman describes why that isn’t a good idea, especially regarding stories that are too big.
I've been working with folks making their transition to agile. One of the hardest transitions is for the managers and technical leaders.
Managers are accustomed to working in timeboxes. To them, the iteration is a timebox. But, they also are accustomed to features spanning multiple timeboxes, and that’s not OK in agile.
They are accustomed to predicting the end of the project, and they now want to use the team's velocity and the story sizes to predict the end of the project. That’s OK, but it’s not always wise. It assumes nothing will change, but agile is for fast change. The managers' fixed mindset is bumping up against the technical team's change mindset.
This leads me to a root cause. If you think your job is prediction, you don't change the size of the stories, and that means the stories are too big. The stories are epics.
It's fine to start with epics—very large stories. But, in order to have releasable product at the end of an iteration and to keep iterations short enough to get feedback often enough, you need small stories. That means you'll start with epics and decompose them into stories. At first, this seems impossible.
Here's one way to start. What's the first valuable thing—the smallest chunk that delivers business value to the customer, to the developers, to the testers, to someone—that we can do that we can show to someone at the end of a short iteration? Is that small thing a story? Is it small enough to be completed inside an iteration, maybe by the entire team? If so, complete that story in the iteration. If that thing is not a story, what would make it a story? If it is not small enough, can you decompose it further?
Making stories small enough to finish in a one- or two-week iteration is a common stumbling block for many teams in their transition to agile. Until a team can do that, they can't move to agile. They can't take advantage of kanban either, because their stories are too big—nothing will move across the board.
This thinking challenges several assumptions on the part of managers and technical leads:
- That there is one and only one right person to do that work. I'm not saying people are fungible. I'm suggesting members of a team swarm around the work.
- That work has to follow a specific order. I'm not saying the work is order-less. I'm suggesting you may have more flexibility than you think at first glance.
- That work has to be a big huge chunk in order to be done. I know that you can work in inch-pebbles. You have to do something first. You have to do something next. I know this.
- That work must only benefit one persona. I'm suggesting work can benefit not just the eventual customer, but the developers, the testers, the marketing people, the trainers, and even HR or legal. Please do not start your stories with "As a customer." Which customer?
Managers and leads are accustomed to thinking big about projects. They have needed to, in the past, because their managers asked them to estimate the entire darn project or, even worse, the entire program to see when it might end. They think they need to know velocity now to estimate the entire project. They still might.
But, they can't do that if stories span iterations. They can only be successful if the teams complete stories inside iterations. Teams cannot get partial credit for stories. Partial credit perpetuates work in progress, which is a very bad thing , no