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:
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.
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.
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!
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.
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.
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?
Jun 14th was the first productcamp in Austin (and the second one anywhere). It was a great event, and here’s the presentation that I did on how to define the strategic problems that drive our products.
We know the importance of identifying the use cases that enable our business goals. We also know the value of understanding the actors that will use our products. This article shows how to demonstrate a simple but powerful view that maps the use cases to the actors.
The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!
Free RSS subscription
(more...)
Subscribe to comments RSS for free
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Aug | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
 |
These articles are written primarily for business analysts and product managers. Hopefully they help with thinking, doing, and training. Welcome aboard and let us know what you think!
