Implementing User Stories in a Waterfall Paradigm
From the pmStudent Blog
by Josh Nankivel
Ranting and raving about project management and systems engineering.
Recent Posts
The Problem with Project Management
The Problem with Project Management
The Problem with Project Management
LinkedIn Recommendations Are Easy
The Catch-22 of Project Management Certification and Experience
Categories
Agile,
Career Development,
Certification,
Change Management,
Communications Management,
Cost Management,
Documentation,
Earned Value Management,
Education,
Integration and Test,
Kanban,
Leadership,
Lean,
Lessons Learned,
Methodology,
Misc,
Multitasking,
New Project,
Operations,
Planning,
PMP,
Productivity,
Professional Development,
Project Estimation,
Project Leadership,
Quality,
Requirements Management,
Risk Management,
Schedule Management,
Scope Management,
Software,
Systems Thinking,
Tools,
Video,
Work Breakdown Structures (WBS)
Date
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 |
 |
 |
Posted on: February 26, 2011 09:42 AM |
Permalink
Comments (2)
Please login or join to subscribe to this item
Glen Alleman
Vice President Program Planning and Controls| Niwot Ridge LLC
Niwot, Co, United States
Josh,
Why won''''''''t the User Story paradigm work on larger programs? The essence of Capabilities Based Planning is to:
Define the Operational Concepts as Capabilities:
• Partition system capabilities into classes of service within operational scenarios
• Connect capabilities to system requirements using sysML
• Define Measures of Effectiveness (MoE) from the customer point of view
• Define in the delivery schedule the achievement of each Technical Performance Measure
Define Capabilities through Scenarios or Use Cases:
• Define scenarios for each system capability
• Connect these scenarios to a Value Stream Map of the increasing maturity of the program
• Assess value flow through the map for each needed capability
• Identify capabilities mismatches and make corrections to improve overall value flow
I'd suggest going back to the "needed capabilities" paradigm and answer the question "why do we need this?" The answer is driven by the notion of
"Define the set of capabilities to be employed to achieve desired objectives or a particular end state for a specific scenario. Take the ConOps and define the details of who, where, and how it is to be accomplished, employed and executed."
You can trace the "needed capabilities" to requirements easily with anything from sticky notes to DOORS.
Elyse Nielsen
Senior Project Manager| Ascension Health Information Services
Haines City, Fl, United States
Hi Josh,
As a pm, it is our responsibilities to assure the team share the vision of what the project goal is. User Stories or Scenarios is just one key tool in that chest. If the tool looks like it will work, I would suggest using it to achieve the understanding.
Please Login/Register to leave a comment.
|
"If you don't know where you are going, you might wind up someplace else."
- Yogi Berra
|
