Paul Brown

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.   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

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