In Retrospect: About Requirements Management

This is the first of several posts in which I’d like to share some of the things we decided throughout 14 sprint retrospective. Some of them might appear as open doors, but I wish I knew or thought about those before I started that project. Just by looking back at the mistakes a team of 9 developers and one tester in a period of 12 months made, they apparently aren’t that obvious.

To provide some context, I’m talking about an ASP.NET project involving the development of a suite of configurable and extendible products, developed in ASP.NET WebForms and executed using Scrum and XP. I was the Scrum Master, architect and lead developer (although those latter roles don’t officially exist in Scrum).

Groom your product backlog
The product backlog should be your single point of truth in terms of which functionality to build in what order. You should not keep any other lists than that backlog, particularly if you’re the product owner of the team (like ours). In other words, whoever and whenever asks you about the status of the project, you should be able to deduct it from the backlog. You should continuously maintain the order of the stories and not only before a sprint planning meeting or when some manager is requesting a status. As team member, beware that you never work on something that is not on the product backlog. And yes, that means that even technical work needs to be represented by a story.

Create a user interface mockup
Earlier in our project, we discovered that most developers are generally poor UI designers. Not only did they create rather non-intuitive interfaces, those also required a lot of rework. At that point we decided that a user interface mock-up was a requirement for every story that involved non-trivial UI changes. That helped not only during the sprint itself, but also during the sprint planning meetings. Having a visual representation of a requirement can significantly improve the estimations.
One note though. Even if your product owner is a master in PhotoShop (ours was), beware that a detailed mockup might cause your team to spend too much time on getting the actual product pixel-perfect. That’s why I prefer tools like Balsamiq. They provide much more room for working towards a good-enough user interface.

Worship the Ubiquitous Language
The Ubiquitous Language is a practice originating from Domain Driven Design and forces all stakeholders involved in a project to make sure they use the same terms for the same concepts, and different terms for different concepts, everywhere. That sounds rather trivial, but isn’t in reality. Especially within larger corporations it is quite common to violate those rules. We’ve learned that investing in this requires quite a lot of discipline but has saved us from many interpretation problems. Just make sure that whenever a term changes (e.g. because of new insights), change it in documentation, in code, in unit tests, everywhere.

Don’t waste time on a glossary
Considering the importance of the Ubiquitous Language, we thought that having a glossary with all those terms (and the differences between our customers) was worthwhile. However, after a few sprints that glossary became hopelessly out-of-date. And after discussing this in the retrospective, we found out that most people in the group were using the coded domain model as the definitive source of any concept or term. So if you go that direction, make sure the domain model is properly documented.

Define the what, who and why of each story
The best understood stories were those that listed the what, the who and the why. In other words, what person or role is going to benefit from a specific feature, what does it allow him or her to do, and why does he or she need it. Don’t underestimate that last crucial part. More than once, it allowed us to come up with a better solution than the product owner initially thought off. In fact, we even managed to get rid off some stories because some other story already allowed that person to do same in a better way.

All stories must have a proper How-to-Demo
The how-to-demo is a short list of steps that illustrate what a story is about. Initially our stories didn’t include a how-to-demo, and the product owner had to spent a lot of time explaining the team how a story affected the system. Worse, it was not uncommon for the team to lose track of the story’s purpose later on. But after introducing the how-to-demo for every new story, the situation improved a lot. In fact, when we started discussing the how-to-demo during the sprint planning meetings the team managed to reveal several inconsistencies and/or oversights in the product’s feature set.

Schedule regular product backlog meetings
One of the most typical aspects of this project was the lack of time the product owner was available to the team and the pressure his customer was applying on him to deliver new functionality. This resulted in two symptoms. First, the stories scheduled for the sprint planning meeting were not of enough quality (e.g. missing how-to-demos, functionality that wasn’t thought through, or stories that still required a mockup). Secondly, at random and usually very inconvenient moments, he wanted to discuss some change requests and get preliminary estimations for them. We worked around this by introducing weekly backlog meetings that we used to discuss new change requests and/or enhance the backlog with missing details.

Well, that’s it for this first short episode in this series of blog posts. Remember that these are the experiences of me and my team, so they might not work as well for you as they did for us. Nevertheless, I’m really interested in learning about your own experiences, so let me know by commenting on this post or tweeting me at ddoomen. Next time, I’ll be sharing my best practices for efficient sprint planning meetings.