Community in read only mode June 18 & 19
This community will be set in READ ONLY mode for a while on Tuesday June 18 into Wednesday June 19 while we import content and users from our Micro Focus Forums community site. MORE INFORMATION

Invitation to a Conversation

Invitation to a Conversation

A story starts as an idea to improve the functionality or appearance of a product. It doesn't have to be a completely defined idea. It can just be a reminder of an idea that can be brainstormed and defined at a later date. For example, a QA engineer who is adding the same standard tasks to each user story for a sprint from scratch for the umpteenth time thinks "Wouldn't it be great if the sprint management tool automatically added these tasks to all of the stories?" He doesn't want to lose that thought so he writes up a "story" as a promise to have a conversation about it at a later date with the product manager and/or developers of that tool.

The story provides the beginning of the concept - an overall picture of who is involved and the goals they want to achieve. You don't have to have an ending when you first write it. It is an invitation to conversation that says "This is what I want to do, can you help me find a way to do it?" - a fuzzy goal that gets the idea moving but doesn't blind the team to other opportunities.

There are three common variations of the standard format that can be used to write your story statement to keep them short and sweet but each team can, and will, create their own:

  • As a [role], I want [feature] because [reason]
  • As a [role], I can [feature]
  • As a [role], I can [feature] so that [reason]

As a QA engineer, I want a way to automatically add standard test tasks to every story because I waste a lot of time adding the same tasks each sprint.

It isn't important to have a solution at this time. That will come later when the developers pick up the story and start to brainstorm ways to achieve the stated goal of helping people to not waste time adding the same tasks every sprint. By going into too much detail early on, you will box in the developers and maybe prevent them from seeing a better solution or an opportunity to expand on the idea. Maybe this is an issue that applies to more than just the QA engineer. Maybe there are multiple ways to resolve the issue - from the bare minimum all the way to a complete rewrite of a section of code. For now, you have set a fuzzy goal that will be defined in a later conversation.

How does your team handle stories? Who writes your stories and how do they get added to a sprint?

Interested in what I'm reading? Here is a sampling:

Tags (2)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Version history
Revision #:
1 of 1
Last update:
‎2012-06-21 16:58
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.