In Retrospect: About Requirements Management - Init

<body> <h1>In Retrospect: About Requirements Management</h1> <p>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. <p>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). <p><a href="http://lh6.ggpht.com/-LKDOWF2RMjI/ToAPUnjfD-I/AAAAAAAAIic/gqPPlKwJFhE/s1600-h/clip_image002%25255B7%25255D.jpg"><img style="display: block; float: none; margin-left: auto; margin-right: auto" title="clip_image002" alt="clip_image002" src="http://lh5.ggpht.com/-5-0WD0iFcVw/ToAPVamPHoI/AAAAAAAAIig/A0Jykwc9N5s/clip_image002_thumb%25255B4%25255D.jpg?imgmax=800" width="238" height="317"></a> <p><b>Groom your product backlog</b> <p>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. <p><b>Create a user interface mockup</b> <p>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. <p>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 <a href="https://mysite.aviva-solutions.net/personal/yodahosting_Dennis_Doomen_aviva/Personal Documents/Although%20formal%20roles%20like%20that%20don’t%20exist%20in%20Scrum,">Balsamiq</a>. They provide much more room for working towards a good-enough user interface. <p><b>Worship the Ubiquitous Language</b> <p>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, <u>everywhere</u>. 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. <p><b></b> <p><b>Don’t waste time on a glossary</b> <p>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 </body>