Thursday, October 28, 2010

User Story Screen

The user story screen is the starting point for all work. It tells a story from the user perspective that we can use to determine what work needs to be done. This story should be short so that the work can be done in a couple of days. More complicated stories should be broken up into smaller stories so the work can be broken into pieces. My rule of thumb is if the story is takes more than a paragraph or so, you need to break it up.

Here’s the User Story screen from VS.

User Story 

Title – A one sentence description of the story.

Assigned To – The single individual responsible for the story.

State – Indicates the current state of the story.

  • Active – The story is currently being worked on or waiting to be worked on.
  • Closed – The story was closed without being resolved.
  • Resolved – The story was completed and implemented.

Reason – The reason the item is in the current state. Matching states are in parenthesis.

  • New – A new story (Active).
  • Abandoned – The story was no longer relevant (Closed). 
  • Out Of Scope – The story does not fall within the scope of the current project (Closed).
  • Rejected – The story was not desired by management, too complex or violates system integrity (Closed).
  • Code complete and unit tests pass – Work has been completed and all unit tests pass (Resolved).

Area – The functional area of the application such as clients, services, etc.

Iteration – The iteration of the system where the task will be worked on. This may correspond to sprints but it could be version number based.

Stack Rank – The relative importance of the item to the product owner(s).

  1. System/process must support this user story / functionality
  2. System/process should support this user story / functionality
  3. System/process could support this user story / functionality

Story Points – An indicator of the complexity of the user story. This value allows for comparison between stories based on an abstract value rather than time (which is not the same between developers).

Risk – The level of risk to the project if the item is not completed.

A Simple Man’s Guide To Using VS & TFS 2010

One of the areas I personally struggle with is planning and organizing. I’m a doer. Git-r-dun! I can see a task and wiz through coding it. As long as I’m the only developer, this works great. When you’re the team lead, it’s not a good thing. What ends up happening is that everything is in your head. The team doesn’t know what to work on and the users don’t know the status of the project.

Want to know if you’re in this category? Take a day off and see what happens! If you come back and find that things have gone haywire, welcome to the club.

So what’s the solution? For me, learning Agile and Scrum basics and using VS/TFS 2010 to keep track of stuff. For the next several posts, I ‘m going to document how we’re going to use VS/TFS 2010. If you’ve done it differently, please let me know. I’ll update this post as the master to keep track of everything together.

The first step will be to create a user story for each discrete activity. Then we’ll write the test cases that insure things are working correctly. Finally, we’ll create the tasks for the actual coding. The following links cover each of the items in VS/TFS 2010 and how we’ll be using them.

User Story

Test Case