A story describes a change or feature that you can move through to a single release. A story is a useful concept for any Agile process, including continuous Agile. Your developers will be much more effective if you give them good stories.
We write stories down in an online ticket or issue tracking system. This gives us a place to discuss the story, sometimes in great detail. We can look at the ticket to see who is working on it, what code changes are related to it, and where the changes are in the code contribution process.
Stories will often have implementation tasks attached to them. They may also be an element of an epic, or of an even higher level topic. The full planning hierarchy is:
It is a good practice to do your backlog planning and estimating with epics and stories, but hold off on expanding the stories with implementation tasks until you are ready to pull them off the backlog and start work.
Make a new implementation task if you think a new developer or designer or tester can pull it.
When you post bug reports for a story, post a new task ticket for each bug. Then you can test and close one bug at a time without being confused by other issues in a long discussion thread.
Traditionally, a story has the structure "As <a persona>, I want to <product functionality/action>, so that <benefit/goal>." For example, "As a reader of this eBook, I want to see a NEXT: link on the bottom of every page, so that I can move to the next page without constantly scrolling back to the menu."
You should include:
Now, combine them into a use case or a user scenario. This is where you really tell a story. Pick a real or close-to-real person to represent the persona. Provide an example of how this person is using the system. Give real example(s) in a full paragraph. This helps others on the team understand the user's perspective and situation. If we agree on the use case, we are free to be creative in how we design and develop.
Never send a story to developers without a clear description of the user and use case.
If you are defining a new feature, you will be tempted to expand it with many new ideas. But too many ideas make a story that is difficult to design and deliver. Before you go to implementation, find the element that has the most value. Shrink the story by taking out everything that you do not need.
If you have a solid use case, you can forward the story for design and development. You don't want to block the design process. You want design to be a process of discovery and flow. However, if you have additional information, you should add it to the story. Here are some of the types of information that are useful.
Feature description.
If you know what the action will look like, describe it.
Implementation tasks.
If you know the steps to implement, list them. This will help when the story is expanded into a list of implementation tasks.
Drawings, storyboards and mockups
Make a quick sketch, or print out and mark up a screen to show how to implement the action. Snap a picture of a whiteboard or a pencil sketch, or export a wireframe from a drawing or presentation program. A storyboard is a flowchart showing the steps or screens for the action. A mockup is a complete picture of the feature in HTML or PowerPoint form. But do not create a final mockup. At this stage we want clarity, but not perfection.
Architecture and architecture questions
Include an architecture discussion if there are changes to data structures, or UI libraries, or data objects, or server processes. If there is a question about architecture, assign a single developer to make an architecture proposal, because group discussions rarely deliver a good architecture.
Acceptance test cases
Most features have many logical use cases. If you write specific tests for each case, it will be easy for developers to produce correct features without a lot of iterations. This can save you time in both development and testing.
Beta and post-release tests
List feedback expected from the normal beta test, and information required beyond that. What measurable changes are we expecting? How can we check those?
Unveiling
Who will we release to first? List any specific unveiling plans or conditions.