Cameron Philipp-Edmonds: All right, today we have Andy Berner of QSM and he's going to be talking to us today about his session titled Grooming the Backlog: Plan the Work, Work the Plan. To start things off, thank you for joining us and can you tell us about yourself and your role at the company.

Andy Berner: Sure. Thanks Cameron. I've been with QSM a little over two years after many years with IBM Rational and several other companies before that. I guess I've been in this industry more years than maybe I care to admit. QSM is a company that provides consulting and tools for software estimation and project control. I'm on the development team for those tools, but I'm also focused on making sure that our tools keep up with new methodologies such as agile. QSM has been in business over thirty years and we've seen probably every methodology that exists. We try to make sure that our tools stay adaptable and up-to-date so that they can be used with modern methods.

We try to make sure that customers can tailor our tools to fit their agile environments. I'm also involved with integrations between our tools and other tools throughout the software life cycle.

Cameron: What led you to the idea of your session?

Andy: We've done a lot of research at QSM. We've been doing more and more research on the factors that make agile projects successful. One key factor that we found is making sure that there's enough time and efforts spent on getting the requirements right. Agile coaches recognize and even emphasize the importance of grooming the backlog but we've seen that there is less information available on what that work actually entails and how you plan and make sure that you have the resources that you need to do it.

We thought it would be valuable at the conference to say more than "you ought to just do it" and really help folks anticipate the resources and the effort that they'll need to put in. And be able to set the expectations on what's going to be needed to keep that backlog groomed.

Cameron: Your session covers the best practices and how to really just be super successful at grooming the backlog. Really, why is it important to groom the backlog?

Andy: It's incredibly important. Agile coders can really only stay as productive as the requirements that they're given. They have to have well-thought-out requirements at the start of each iteration. Vague requirements and requirements churn are just as much of a hindrance in agile projects as they are in any other kind of software development. It's especially difficult in agile because we get going right away. You always need a steady flow of groomed requirements. We don't have the luxury that you might have in some other methods of a big upfront requirement phase to get everything straightened out in advance, which of course causes inevitable delay in the development.

At least you have a chance to get some of that churn removed before the developers even see it. In agile, you have to keep at it iteration by iteration. If you don't keep the backlog groomed, the developers can't do their jobs.

Cameron: Now, you believe that after your session attendees will be able to take back to their team new ways to plan for a well-groomed backlog. As cited in your presentation summary, a well-groomed backlog is something you feel everyone's project and team deserves. Is it cruel and unusual punishment in this day and age to force a team to succumb to backlog chaos?

Andy: Absolutely, it is. Not getting requirements right has been the cause of chaos in software development for forever and that's still true with agile techniques. We talk in agile about embracing change but that's different from requirements churn where you're constantly changing what's demanded because you haven’t thought it out well in the first place. That churn is a productivity killer. Unlike the change that we know how to manage in agile, you don't want to keep changing because you haven't figured out what you're trying to do.

So, you can't just say it's up to the product owner to get it right. Bob Galen in some recent conferences has talked about it "taking a village" and discipline to keep the backlog groomed. Requirements have to meet the definition of ready, ready to be turned into working code and it's not fair to hold a team of great developers hostage to an undisciplined backlog.

Cameron: OK. So, it definitely is cruel and unusual punishment?

Andy: Yes, it is.

Cameron: As one can imagine, getting your backlog ready, it really takes a lot of work and planning. You've also narrowed down five key issues to consider in planning that will help setup for the project for success. Can you share at least one of these keys with us?

Andy: Sure, let's talk about keeping two views of the backlog. Classically in agile methods—it's amazing that we can now talk about classically in agile methods—the backlog is a prioritized list of user stories, it's a flat list of the stories in the priority order so that the ones on the top can get pulled off for the next iteration. That backlog gets re-prioritized iteration by iteration. But as iterations have become shorter and shorter, you have to make sure that those top stories that are being pulled off in the next iteration are broken down into developer-sized bites, small enough stories that can be developed within one iteration.

Those small stories probably started off as parts of large stories that you've broken down stories or epics or features, whatever terms you want to use, that you broke down into the small stories that can be developed in each particular iteration. Those details, therefore, are not just part of that flat list, but part of a hierarchy of features. And so that hierarchy is what gives these developer sized bites the meaning and the context to the business and that's what lets the business know what creates value to the business. It's important to keep that hierarchical view in addition to the list of prioritized stories.

There are several techniques that we see in the agile literature for doing this. There's a notion Jeff Patton introduced called user-story maps. There's the notion of minimal marketable features. You can use traditional requirements hierarchies. It doesn't matter too much how you do it. However you do it while you're grooming the backlog, you have to track both that prioritized list of stories but also that hierarchical view that shows the value to the business and lets the business know that they're developing the right software.

Cameron: That's really great. In reality, I never even thought about looking at those two views, that's really interesting. I look forward to ...

Andy: It's really two views of the same content.

Cameron: Yeah. I look forward to seeing the other four keys in the presentation. Moving along here, how does the application of metrics fit into grooming the backlog?

Andy: Metrics is QSM's business. How grooming the backlog progresses during the course of the project has some immediate consequences. If the backlog is not groomed, then there's no stories to develop in the next iteration, those are fairly easy to see. But not grooming the backlog well enough can also have consequences down the road. You need an early heads up on those down the road consequences. In the talk will be giving at Agile East, I'll describe three metrics and a milestone, we'll show how those metrics will help you see early whether the work is progressing according to plan.

In QSM's SLIM-Control for example, when you track values of a metric, you not only see the actuals up to that point and the shape of the curve of the actuals; we've all looked at burn down charts and seen whether the shape of the burn down chart is right. But you also compare that shape to what you expected based on your plan and you can evaluate the variation between what you're actually doing and your plan and of course there is variation, things never go exactly to plan.

Sometimes you're ahead, sometimes you're a little bit behind. But you can see whether that variation is within an expected control bounds and you're doing just fine or is that variation showing you that you're falling way behind long term. That gives you an early head start to realize that there is some corrective action you can take maybe to get back on plan or maybe you actually have to re-forecast the project. But, without keeping those metrics, you can't get that early head start. You only see the consequences when it's a little too late to react to them.

Cameron: All right, so metrics kind of help to be proactive instead of reactive?

Andy: Absolutely.

Cameron: Fantastic. Now, you have also spoken before on some tools and methods with emphasis on making sure that tools serve the team and not the other way around. When I first read that, I have to admit, embarrassingly I first thought Blade Runner and some of the other Sci-Fi movies out there. While a very humorous notion, unfortunately, you know it is also true at more times than it should be. So how can team members make sure that they are controlling the process and not the tools in control over them?

Andy: Yeah, that's tricky because you're introducing the tool in order to change and improve your process, that's the reason you're introducing a new tool. You can't just expect to use the new tool and work exactly the way you were currently working because then you're not going to get the improvement you want. You also want to be sure you never fight the tool, but you want to be sure that you're still in control and that the tool is serving you and not the other way around. Both the process and the tool have to be flexible. With all that in mind, here's a few guidelines you can think about.

First on the process side, you want to make sure that you understand the goals of your process. You're not just doing things because that's how we've always done them, but you're doing things for a reason and it's that reason that you want to maintain when you're introducing the new tool. And you want to be able to do that better. When you're evaluating the tool, also evaluate how the vendor approaches this very issue. Do they try to understand what you're trying to accomplish and then help you see how their tool helped you do that or did they just show, here's how our tool works, and take it or leave it?

When you're looking at comparing tools, make sure any tools that you bring into your environment are highly configurable. You don't want a tool to work just one way and that's the way that you have to use it. You want to be confident you won't be boxed in too much by the tool, even though in many cases you probably will start with some out-of-the-box configuration but you want to make sure that it can grow. You also want to make sure somebody on your team is trained in doing that kind of configuration. Because nobody understands better what your team is trying to accomplish than people on your own team.

Cameron: Exactly.

Andy: Inevitably, though, you are going to need some help from the vendor. Tools are complicated to use and processes are complicated and you're going to try to figure out how can I make this tool do what I want it to do. When you're asking for help from the vendor, make sure again you focus on what you're trying to accomplish—not just the little stumbling block you ran in the configuration. Because that way the vendor is going to find the best way to meet your needs and it might be going down a whole different road from what you were trying to do.

Whether it's your team or the vendor, make sure that you always start with the question, 'what do we want to accomplish with this process,' and then look at how is this tool going to help us do that.

Cameron: Of course, like you said earlier. Avoid those famous last words, 'this is how we've always done it.'

Andy: Have you ever heard the term QWERTY phenomenon.

Cameron: I have not.

Andy: The keys on the keyboard.

Cameron: Right.

Andy: The layout of the keys on our keyboard are that way because that's how it's always been.

Cameron: All right. In addition to speaking, you're also a writer and you've written several articles on the importance of setting realistic expectations during the planning stage.

Andy: Right.

Cameron: Do you think a lot of projects are consistently failing to meet expectations whether those expectations are fair or not?

Andy: Yes. Unfortunately, our experiences at QSM show that that's still the case in software development. And your qualification, whether fair or not, is a really good one. Often the expectations that are put on the project never even had a chance to be met. There are too many projects that are charted based just on wishful thinking. You know the scenario, an executive says, "You can get all this done in four months, right?" Because many companies still don't keep history of the work that they've completed, nobody has the nerve to say, "No, we can't do that," because you don't have any way of proving that you can't. In the field of software estimation, we talk about the impossible zone.

That's where somebody has some expectations about the cost and the schedule of a project, that not only is a stretch, but it's never been achieved by any comparable project anywhere. Too often projects are charted in the impossible zone. QSM has a database of thousands of completed projects. Many of our customers share anonymously the data on their completed project, so we have very good industry-wide data. We believe that when you charter a new project, you can use your own history which is best, but if you don't have that you can use our industry-wide data to set realistic expectations based on what's done before.

There's nothing wrong with asking your teams to stretch. There's nothing wrong with expecting improvement. And those may or may not succeed to some degree, but if you expect the impossible you're bound to be disappointed.

Cameron: That ties in earlier about metrics helping to be proactive versus reactive.

Andy: Absolutely. The reason for collecting those metrics is to take some action with them.

Cameron: All right. Fantastic. Now getting away from software for a second, and I see the picture in the background there. You foster retired racing greyhounds in an effort to help them transition into becoming household pets.

Andy: That's right.

Cameron: How do you get started doing such a noble act?

Andy: Thanks for asking. About ten years ago, we were in a pet store to get some food for the cat that we had at that time, and one of the local greyhound adoption groups had what we call meets and greets where they have four or five greyhounds at the pet store. They're to introduce people who haven't met greyhounds before to the breed. Everybody thinks greyhounds are running around all the time and actually they're the most gentle, sweetest dogs that you've ever met. We totally fell in love with the breed and after adopting our own girl and seeing how much we gain from having her in our home, we felt that we needed to give back to the group and help foster others so that other adoptees can have the same experience we had.

There are greyhound adoption groups all over the country and I'd really suggest your listeners check those out. There's even a very active worldwide community of greyhound lovers on Facebook.

Cameron: Fantastic. Is that yours behind in the picture?

Andy: It is. She's the girl, the first greyhound girl that we got.

Cameron: All right. Fantastic. Now, is there anything you like to say to the delegates of the Agile Development and Better Software East before they attend the conference?

Andy: Sure. Agile methodologies have matured enough that the question now is not 'is agile a good idea,' but it's really how can we adapt and improve our use of agile techniques. The Agile Development and Better Software East Conference is going to be a great place to learn both basic principles and practical applications whether you're new to agile, whether you're experienced, or whether you're an expert. As I said when we talked about tools following process, when you're at the conference focus on what are you trying to accomplish with your agile methods and how this helps us accomplish it, and listen to the talks with that in mind.

Software development is hard and the conference is going to be a great venue to learn and take back techniques that are going to help you do that hard work better. While you're at the conference, please stop by the QSM booth at the expo. We'd really love to meet you.

Cameron: All right. Fantastic, Once again, this is Andy Berner of QSM. He's giving the presentation entitled Grooming the Backlog: Plan the Work, Work the Plan. Make sure to check it out and meet with him there at the conference. Thanks so much, Andy.

Andy: Thank you very much.

 

For more than twenty years, Andy Berner has helped organizations improve their software development processes. With hands-on experience in almost every software development role, Andy now leads the work at QSM to incorporate agile techniques into QSM's SLIM suite of software estimation tools. He has published several articles on agile methods and practices, focusing on planning projects to set realistic expectations. A frequent conference speaker on software tools and methods, Andy emphasizes how to make sure that tools serve the team—not the other way around. He spends his spare time fostering retired racing greyhounds and helping them transition to loved house pets.