Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical. When you set unattainable goals, the best result you can hope for is a frustrated engineering team. Write requirements that are attainable, and your team will surprise you with what they can achieve.
Category Archives: Requirements Models
Design-Free Requirements
Design-Free requirements are important for two reasons, and hard for two other reasons.
Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.
Read the rest of the article …
Kano Analysis for Product Managers
Kano Analysis, while initially created to understand customer satisfaction with features, can be used by product managers to better understand customer problems. I gave a presentation last week for the Product Management View webinar series on Kano Analysis for product managers.
Read the rest of the article …
Concise Requirements
Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things:
- Identify the problems that need to be solved.
- Explain why those problems are worth solving.
- Define when those problems are solved.
Read the rest of the article …
Valuable Requirements
Writing valuable requirements is important. It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features. The right products and capabilities are the ones that have relevant value.
- Valuable requirements solve problems in your market.
- Valuable requirements support your business strategy.
- Valuable requirements solve problems for your users.
- Valuable requirements meet your buyers’ criteria.
- Valuable requirements don’t over-solve the problems.
Read the rest of the article …
Writing Complete User Stories
User stories can make requirements management a lot easier. They shift some of the communication from up-front documentation to ongoing dialog. That’s the main reason they work so well for agile teams. And agile teams focus on “what’s next?” instead of an ever-changing “what’s everything?” The problem is, when those conversations are working well, it is easy to forget to make sure that what you’ve done is actually enough. Add a small dose of traceability, and you can easily validate the completeness of your user stories.
Read the rest of the article …
Failure To Launch (Your Product)
Jump forward in time to the day of your next big product launch (first release, new features, new market segment, etc). And your site/application crashes due to the “unexpected” demand. All you can do now is look for a bucket of water to put out the fire. What could you have done to prevent this disaster? Jump back to today and start doing it!
Read the rest of the article …
Agile Non-Functional Requirements
Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint. See one way (that is working) for managing non-functional requirements with an agile team.
Read the rest of the article …
User Stories and Use Cases
User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first. They differ from use cases in some important ways, but share more commonalities than you might think.
Read the rest of the article …
Agile Product Management: Providing Context
Agile development methodologies succeed because they help development teams be as effective as possible. Development teams do not, however, work in complete isolation. The company they work for has a strategy. The company manages a portfolio of products, and targets a particular product at specific market problems. Within that context, an agile team can thrive. What’s the best way to provide that context?
Latest Articles
Comments on all Articles
