Agile Best Practices: SVP of Engineering Jeff Nielsen on Iteration Planning

Most software development teams work in such a way that the majority of the requirements planning falls onto the product manager and disrupts the cohesion of the team itself. 3Pillar Global’s SVP of Engineering, Jeff Nielsen, discusses how to structure iteration planning meetings so as to avoid useless requirements work.

Transcription:

Have you ever experienced the magic of just-in-time requirements work? Most people haven’t. And in fact, this is one of the biggest problems with the traditional approach to software development—that a lot of requirements work that gets done ends up being waste. As Mary Poppendieck has said, “If you have a lot of requirements churn, then you are specifying too early.” This is a huge problem.

And it’s a problem that even agile teams run into. I see teams all the time where the BA or the product manager feels like they have to work one or two or three weeks ahead of the team, writing down a whole bunch of detailed requirements so that the team can be ready to start an iteration. And it doesn’t have to be that way. If we are using the user story construct properly, then most of the detailed requirements work for a user story can be done within the actual iteration. When that happens is in the iteration planning meeting, which is what we are going to talk about for a few minutes here.

Picture this vision of an iteration planning meeting. You’ve got the whole team there in a conference room—testers, developers, managers, analysts—with a big whiteboard. You’ve brought in six or so stakeholders, customers, and/or representatives from the business. And you’ve got a set of user stories that, based on your high-level affinity estimation, you believe will fit into the current iteration. Then you go through each of these user stories one by one and talk about what will we actually build over the next several days to implement this user story: what are the acceptance criteria for this user story, what’s the happy path through the scenario, what are some exception cases, what are some bizarre things that we haven’t thought of yet that we need to account for as we build this?

And as everyone is taking notes, you end up with a pretty good sketch of the acceptance criteria for each of these user stories. And with all those minds focused on that single story—on what we are actually going to build over the next couple of days—you can get a lot of good requirements thinking done in a very short time (maybe 10, 15, at most 20 minutes per user story).

That is an effective iteration planning meeting, where everybody walks out with a shared understanding of what we’re going to see 9 days later in the iteration review for each of those user stories. And I promise you that is the best time to do that detailed requirements work. That’s why I call it the magic of just in time requirements.