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 matter what agile or lean approach you are using.

If senior management needs to know how long the entire project will take, the best way is still to explain, "We need three iterations to be able to estimate. We will track our velocity for three iterations and give you a reasonable three-point estimate at the end of that time, OK?"

Anyone who won’t wait six weeks, or three two-week iterations, for a reasonable estimate wants a SWAG—a “scientific, wild-tush guess.” In that case, you can say, "Christmas," and don't provide a year. This is the "Happy Date" schedule game. You’ give them what they want to hear, because reality will intrude soon enough.

If you are transitioning to agile, here are guidelines I have found useful:

Make your stories small enough so that you, the team, can finish more than one story inside an iteration. My rule of thumb is that you should be able to complete a story every day or, at worst, every two days. If you can complete stories more often, that's even better. If you can't complete a story at least once every two days as a team, your stories are too big. Yes, there are exceptions, but you'd better have a darn good reason.

Remember that velocity is personal to a team. As soon as you change a team's makeup, velocity can change. So, don't change the people on a team if you want any sort of predictability about estimation.

If you really want some predictability, make the stories really small, so that people can pair on them and still finish them in a day or less. Then, all you need to do is count the stories to have a rough idea of how long the team needs to finish the project. "That's a lot of stories, JR!" Of course it is. That's why you're paying people to work on the project.

I no longer estimate my work. I make sure my chunks of work are tiny. That way, I just keep chugging along. That would work for your team, too.

But, whatever you do, give up the notion of stories spanning iterations. If your stories are big enough that they need to span iterations, stop right there. Stop with the partial credit. Put those stories on a diet. Separate the stories—not into tasks, but into multiple, independent, smaller stories that the responsible person or product owner can schedule into the most appropriate iteration and rank when it's time for that story to be implemented.