Visual studio feeds

All Visual Studio blogs in one place


Enter your email address:

Delivered by FeedBurner

Increase your website traffic with



Anti-spam: How many eyes has a typical person?

Follow us on FB


In Retrospect: About Requirements Management

AddThis Social Bookmark Button
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...(Read whole news on source site)

Home : Blog List : Dennis Doomen.NET : In Retrospect: About Requirements Management