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.

This articles was originally published on TechWell
 

Trackback(0)

TrackBack URI for this entry

Comments (6)

...
written by Russ Rahn, January 19, 2012

Although I don't doubt what Russell is saying is true from his experience, my experience falls more closely in line with Johanna. The epics are used as starting points. My experience is that when a budget estimate is made from that epic point, it often is nothing more than a guess.

However, the problems that I have seen arise from breaking the epics into short stories, and then into many smaller Sprint Backlog Items is that estimates almost always involve a little fudge time. The esimater will think, "Oh, three hours will do it." But then thinks, I have had times where I ran into issues, so I'll fudge this to 5 hours." Adding 2 hours doesn't seem like much, but it is 67%. If this is done for every SBI estimate, you are going to scare the pants off of upper management when you lay down the cost. When it all plays out, some percentage of the tasks take the extra time, but most come in at the original thought.

PMs need to be aware of their team's history, get the estimaters to give their true thoughts without fudging, and then present the budget, including an added percentage based on the team's development history.

• 
• +0
• 
• 

...
written by Paul Marko, January 19, 2012

I don't agree with a story every 2 days. We follow the INVEST model and sized appropriately is our rule of thumb. What we have found is that breaking stories down so small yes gives the team the illusion of moving faster but provides a massive overhead for the BA in writing stories, arranging stakeholder availability and having to stitch togther stories that have become sub atomic!

• 
• +0
• 
• 

...
written by Russell Pannone, December 13, 2011

And yes what I previously commented can and has been successfully done when you have epics. In fact if it couldn't agile prodcut development would be a hard sell in large organizations that have a PMO and do capital planning and budgeting.

• 
• +0
• 
• 

...
written by Russell Pannone, December 13, 2011

Johanna, because our experience differs when faced with estimating buget, when being agile can be done and pragmatically.

See the following for more information:

http://www.agilejournal.com/component/content/6014?task=view

• 
• +0
• 
• 

...
written by Johanna Rothman, December 13, 2011

Russell, my experience differs from yours. With epics, it's quite difficult to estimate budget, as well as do project portfolio management, because you cannot tell when you will be done enough to do a demo, or to know when you have enough money to stop. I have had much more success with smaller stories that complete in an iteration, ranking the backlog, doing demos, and using estimation, as I suggested in this series: http://www.jrothman.com/blog/m...rt-5.html.

The longer the project, the fewer options you have for the project portfolio. Especially if you want an agile approach to it. I wonder if we are violently agreeing.

• 
• +0
• 
• 

...
written by Russell Pannone, December 13, 2011

For most large organizations that are still doing capital planning and budgeting as well as portfolio and program management your suggestion will very likely be meet with dissatisfaction and resistance and maybe even kill the adoption of agile product development.

There is an alternative. Once you have your Product Backlog (including “epic” stories) that was derived from the Product Vision and by gathering agile requirements, there is a reliable technique (as least as reliable as the traditional way of doing this) using the story size, team capacity and a little bit of simple math that can be applied, to come up with a rough order of magnitude (ROM) estimate for the product/project cost, schedule and scope early in the product development lifecycle.

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview