I’ve touched on User Stories on several occasions, my favorite being Why Your User Stories Suck! Today I’m here to share with you a very common, yet very commonly overlooked, way to check each and every User Story on your backlog to see whether or not it’s really “ready” for your Dev teams. One of the most frequent causes of delays and slowdowns in most Agile implementations that I’ve seen comes from a lack of balance in the User Stories that the team is being given to deliver — stories that are too big, or which are dictates, or which just exist on the backlog because “someone asked for it”. What we need to do as Product Managers is to occasionally take a close look at each of our backlog items and make sure that they meet the INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small, and Testable. If we do this simple gut-check on a regular basis, we’re far more likely to see our teams succeed and to reduce the amount of time wasted in long, drawn-out planning sessions.
Ironically, one of the most fundamental tools that Product Managers use every day to communicate requirements, expectations, and user goals to their development teams also sometimes seems to be one of the most difficult things to get right. Maybe it’s because many of us are used to the bad, old days of waterfall requirements, maybe it’s because our developers aren’t used to solving problems, or maybe it’s because our stakeholders and upper management expect certainty in what we’re going to do and how we’re going to do it. Regardless of the reasons, it’s absolutely essential that we master this tool and push for its proper use whenever we can. Properly-formatted, well-written user stories are the cornerstone of a user-centered design pattern — and stating a problem that needs to be solved in a way that allows developers the freedom to solve it in the way they deem most appropriate is a talent that all Product Managers can benefit from. [Read more…]