Defining requirements for a software system has always been a difficult task.  Capturing requirements as User Stories is a technique that has been extensively employed on Agile projects as a way to help describe functionality that will be valuable to users of the software being developed. According to Mike Cohn user stories should be composed of three aspects:

-          A written description of the story

-          Conversations about the story that help flesh out the details of the story

-          Tests that allow us to understand when the story implementation is complete

In addition, William Wake, from “Invest in Good Stories and SMART Tasks,” suggests that there are six attributes (INVEST) of a good user story

  1. (I)ndependent
  2. (N)egotiable
  3. (V)aluable
  4. (E)stimable
  5. (S)mall
  6. (T)estable

Of course, there are other accepted methods for helping to describe software requirements (for example, Feature Driven Development, use cases, scenarios, etc) however, for the first release of TeamPulse we decided that User Stories are where we want to start.

User Stories in TeamPulse have a number of important features.  When you describe a User Story, TeamPulse will start you off with a template.  One of the most common “forms” of a User Story has the following form:

“As a <type of user>,

I want <some goal>

So that <some reason>”


It is really important to have consistent taxonomy of your stories – in much the same way you want consistent coding practices implemented within your software.  Here is an example:

“As a Customer Service Representative

I want the system to provide me with a callers contact information when customers call me

So that I do not have to waste any time getting these details from the customer and I can begin to help them with their problem right away”



There are a few things you should note about this story.  First, there is someone involved with it.. namely the Customer Service Representative.  Second, it describes a behavior and expected outcome from the perspective of the person in the story.

User Stories in TeamPulse

TeamPulse provides you with the tools to capture User Stories, as well as to relate User Stories to what we call “Personas” (which are the characters involved with the stories), as well as decompose larger User Stories (sometimes called epics in the Agile community) into smaller Stories that have better INVEST attributes.

You capture User Stories in the Stories details window in TeamPulse.  As you can see, we provide a rich text description field for you to enter the story details:



(click image to enlarge)

Using Quick Linking when Defining Stories

TeamPulse allows you to spice up how you represent User Story details with the Quick Linking feature.  If you are familiar with Intellisense in Visual Studio, Quick Linking will come very naturally to you.  Quick Linking allows you to quickly add a reference to a Story or Persona within your description text.  If the Story or Persona does not exist, Quick Linking will create a stub for you automatically.  Quick Linking really helps to make it easy to have full traceability between your requirements. 

Here is an example of how this works:


(click image to enlarge)


Notice, once you type the name of the new Persona you will see two things. First, the Persona will be represented as a link in the description field, and second, the Persona will be added to the list under the Persona tab.


(click image to enlarge)



(click image to enlarge)


Using Quick Links you can also easily make reference to other User Stories (either new or existing) in your system. Here’s an example:


(click image to enlarge)



(click image to enlarge)

You should note that after you use Quick Link to reference Persona’s or Stories, you can use the links for navigation (click on the Edit/View button to toggle the Description from Edit to View model to activate links)


Attributes of a User Story

TeamPulse User Stories also have a number of other attributes.


(click image to enlarge)


Estimate:  Represents the size of the User Story.  Some teams may use Story Points to represent size.  Other teams may represent the size of a story in the number of days or weeks estimated to implement.  We have made no assumptions regarding the unit of work for this field.

Priority:  This is a numeric indicator that you can use to help prioritize the Story in relation to other Stories

Priority Classification:  This attribute is a much broader way of defining priority using MoSCoW

  • (M)ust Have
  • (S)hould Have
  • (C)ould Have
  • (W)on’t Have

Value Classification:  This attribute helps to identify the type of value the feature provides to your organization.  We’ve started you off with a few values that we use:

  • Differentiator:  A unique feature
  • Spoiler:  A feature that your competitors have, but your software implements better
  • Cost Saver: Work we must do to reduce the cost of development, support, maintenance, or to increase profit or margins
  • Table Stakes:  A feature you must implement in order to ship

Complexity:  A relative attribute that allows you to express how complex you believe the story is.  Very complex stories may be flagged for greater design work compared to very simple stories.

Maturity:  Maturity represents how mature the story is with regards to its specification.  If you have only just captured the story title and can not quite define the story description, the story is not mature at all.  You can use this flag during planning, as you will likely not want to start development on stories that are not mature.

Certainty:  Certainty is an attribute that allows you to express how certain you are that the story is accurate.  Some stories may be fully written, however, you can use this certainty flag to indicate that you require additional validation before proceeding.

Of course, TeamPulse also allows you to categorize your story into something called an “Area” (short for Feature Area).


(click image to enlarge)

Acceptance Criteria in TeamPulse

TeamPulse also provides a mechanism for you to capture the Acceptance Criteria for a User Story. Acceptance Criteria help us define what “done” means and works as an agreement between your product owner and team to help manage the acceptance of a User Story in a production system.


To capture Acceptance Criteria in TeamPulse, use the Acceptance Criteria Tab to capture the title and description of all the acceptance criteria valid for your User Story.


(click image to enlarge)


As you can see, using User Stories to help define the interaction between users (Personas) and the system is a powerful way of describing system requirements while focusing on flow and value. As always.. please let us know what you think!! We’re anxious for feedback.


Don’t forget about our Launch Webcast happening on the 27th! Register now!



Comments are disabled in preview mode.