Page tree
Skip to end of metadata
Go to start of metadata


On CONNECT, we utilize Agile processes to build software. With this process, new functionality is captured as a "story". A "story plan" is documentation on the acceptance criteria for a set of functionality, often spanning multiple "stories".

Story Plan process flow

CONNECT New Feature Story Plan Process 4_16_10.ppt

List of story plans


Q: What are the goals of the story plans?

A: With CONNECT's implementation of a story plans, the primary goals with story plans are to 1) define when a set of functionality is complete and 2) to serve as a reminder to write an automated test. Bonus/secondary goals are to add clarity to assist during development and to extract detail from the specs to assist during testing; provide a view from a "requirements" standpoint; provide traceability; allow for better estimates; allow for more granular choices by the product owner on which pieces of functionality to implement.

Q: Who are the target audiences for the story plan?

A: The story plan is created for 3 target audiences -
1) Stake Holders/Clients - The story plan gives business level overview of the functionality and explains the user acceptance related to that feature.
2) Development team - The story plan explains in detail the process flow (using activity diagrams) and detailed functionality of the feature.
3) Validation team - The story plan covers detailed acceptance criteria covering all the functionality within that feature that can be mapped with the test cases and at the end can be mapped with the confirmations created within the user story.

Q: Why track this on the wiki? Why not track this with the story (in Target Process or Jira)?

A: There are a few issues. The first is that the amount of data being tracked in a story plan is difficult to manage and view within a single tracking item in TP/Jira. Second, a story plan covers at the "epic" level, spanning multiple stories. Third, whereas the TP/Jira items typically cover a moment-in-time view of the implementation of an item, a story plan allows for the functionality to evolve over time to show the system in its "current" state.

Q: How does a story plan fit into the process.

A: Story plans are to be created about a sprint or two ahead of the expected implementation.

Q: What is the input of a story plan?

A: A story plan takes into consideration the NHIN specification (if applicable), the CONNECT implementation plan (i.e. design), and the product owner (as a proxy to the various customers) view of how the functionality should work.

Q: This sounds very waterfall-ish - almost like creating rquirements during one phase, and then later implementing during another phase. Why is this necessary?

A: There are a few things that makes this different than a "typical" project. To explain, think of a typical web project. The customer can explain loosely what they want, an initial implementation can be done, the customer can refine their expectations, repeat to achieve iterative development. In this type of project, the product owner is able to communicate at a level needed to define the acceptance criteria for a set of functionality. In a messaging system like CONNECT, it requires additional analysis of the specification and propose implementation to properly layout what the acceptance criteria is.

Q: Is a story plan required for all functionality?

A: Nope. It is expected to use story plans for "major" functionality, like implementation of NHIN specifications.

  • No labels