Categories: Agile
Working on a large aerospace project the traditional requirements model applies. On my project user stories have not been used before to my knowledge.
Coming into this project after requirements had already been defined, I find that those requirements are somewhat lacking as a good description of what our software is supposed to do. They also do not function well as a springboard for further conversation. Now that I've been on the project for a while, I am ready to really start digging into using user stories and other agile concepts with my teams.
So far with one of my smaller teams we have been using user stories but not tracing them directly to requirements. This is worked out pretty well for the smaller team, but with a larger more complex project this probably won't cut it. So, now I am starting a new release with one of my project teams and I will be creating a module in the requirements management tool that we use. I will then trace the user stories to the requirements.
I have never done it this way before. In the past, I have always done either completely agile development with user stories and use case scenarios as the primary means of understanding what the customer needs or I have used a straight work breakdown structure and requirements framework.
The current plan is to not configuration manage the user stories at the same level we do our software requirements. With the user stories my team will essentially be the configuration management board, along with the customers for the specific functionality that we are developing. We have many customers including other software development teams, science users, and the mission operations personnel that will be using our software.
Do any of you have experience implementing user stories in a waterfall environment like this? If so I'd love to hear your suggestions and experiences on the topic.
| Share this with your network | ||
 |
 |
|
