Like any other artisan work, it takes years to mature in the "art form" of user creation -- but these five tips will provide rock-solid principles that will point you in the right direction or, at the very least, provide some helpful reminders:
Tip #1: Go for Simplicity
You could make the case that novelists are the ultimate "user story" creators. If you've ever tried to write a novel -- a truly, reader-centric, riveting, fully operational story -- you know it takes a tremendous amount of planning and development, one sentence, paragraph, page, and chapter at a time.
But when it comes time to pitch that story to agents and editors, every novelist must have one indispensable skill: they must be able to sum up the story -- yes, the entire novel -- in one sentence. This magic sentence contains all of the ingredients: protagonist, the conflict that rises against the protagonist, and the goal that motivates the protagonist to overcome that conflict. It's all about who, what, and why.
In a certain sense, it's no different for user story creators. Until you're able to reduce your entire concept into its most elemental properties, you likely don't have a clear enough vision of the project.
All About Agile offers this tried and true formula that uses a one-sentence summary to establish the premise for your user story: "As a (user role), I want to (goal), so I can (reason)."
As the article author notes: "This [one-sentence summary of the premise] helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why."
Tip #2: Think As If You Were the Stakeholder, Not the Developer
We all develop bad habits, and even the best user story creators can nurture them without realizing it. One of the most problematic bad habits is viewing a user story from the developer's point of view and not the perspective of the user.
As AgileModeling observes: "User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks."
Tip #3: Don't Think of It as a Contract. Be Flexible.
If we approach user stories with rigid parameters, it could sabotage our ability to get the job done and get it done well. Every team member must establish an attitude of total flexibility and collaboration beforethey walk into the room to begin work on the user story.
As this article points out: "User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development."
Tip #4: Rely on Teamwork When You Write Your User Story
Tip #3 segues nicely into #4. It's all about teamwork. If we slip into a put-this-into-the-assembly-line-and-walk-away mentality, we miss the point of agile development and user creation. Getting the product owner involved is the key.
As RomanPichler.com recommends:
A user story is not a specification, but a communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.
Although human nature sometimes shrinks away from collaboration -- after all, we get a little nervous when too many cooks step into the kitchen -- we must remind ourselves that this "kitchen," the user story, thrives in a wide-open, flexible, collaborative environment.
For more information on how to write user stories for use in agile development, contact us and learn how our talented, hard-working team of agile experts can help.
Open Up Feed