It seems simple enough. The project sponsor tells the business analyst what they want; the business analyst structures these requirements and documents them; the systems analyst translates this into a technical design; the developer implements the design; everyone checks it and then it goes into production. Only everyone knows its not that simple.
The idea of a "User Story" seems simple too. The project team, which includes someone from the business unit, identify a feature that someone will need in the system. They write it in a simple format: "As a, I want , so that I get . They agree how they will know when the feature is implemented satisfactorily. They give an estimate as to how long it will take, decide its priority, and if the priority is high enough then they implement it.
This idea of user stories originated in Agile project methods and have several advantages over more traditional techniques for gathering requirements. They are written in the language of the business rather than the technology. They are short and apparently simple. They can be clearly prioritised. They explain why the feature is needed, which should be as closely tied to real value as possible. Each one has a clear set of acceptance criteria agreed early on. And they don't try to pin down the design in detail.
We've found them so useful in trial projects that we intend to use them more widely, on waterfall projects as well as agile ones. To help us with this, last week we held an internal workshop, with an external consultant who guided us through some of the techniques, pitfalls and implications. This was really useful. Our next step will be to decide exactly how to fit this into our methodology; then train the people who will be using it and put it into practice.
The idea of a "User Story" seems simple too. The project team, which includes someone from the business unit, identify a feature that someone will need in the system. They write it in a simple format: "As a
This idea of user stories originated in Agile project methods and have several advantages over more traditional techniques for gathering requirements. They are written in the language of the business rather than the technology. They are short and apparently simple. They can be clearly prioritised. They explain why the feature is needed, which should be as closely tied to real value as possible. Each one has a clear set of acceptance criteria agreed early on. And they don't try to pin down the design in detail.
We've found them so useful in trial projects that we intend to use them more widely, on waterfall projects as well as agile ones. To help us with this, last week we held an internal workshop, with an external consultant who guided us through some of the techniques, pitfalls and implications. This was really useful. Our next step will be to decide exactly how to fit this into our methodology; then train the people who will be using it and put it into practice.
Comments