DevOps Zone is brought to you in partnership with:

Dennis is Principal Consultant at Aviva Solutions, speaker, author, coach, specialized in ALM, TDD, DDD, design patterns, architecture, Agile, TFS and Silverlight. He published coding guidelines for C#3.0 and C#4.0 and maintains multiple open-source .NET projects. You can tweet him at @ddoomen Dennis is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile

In Retrospect: About Requirements Management

09.26.2011
| 3388 views |
  • submit to reddit

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).

clip_image002

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 understand 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 of 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.

References
Published at DZone with permission of Dennis Doomen, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Christophe Blin replied on Mon, 2011/09/26 - 7:14am

A few typos :

 * the link to balsamiq is not working (it links to your account home page I think)

 *  "Don’t understand that last crucial part." => I hope you mean "Dont underestimate that last crucial part"

 

Except these, I totally agree with you.

I would  dare to say that the ubiquitous language should be reinforced by functionnal tests expressed with it (the glossary becomes really unecessary becauseyou have the concepts AND their usages.

Paul Russel replied on Sun, 2012/06/10 - 9:01am

Ha Dennis,
Nice (and sometimes recognisable) stories, also the rest of the series.
One detail: the link to Balsamiq is not working.
Thanks

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.