I’ve had an opportunity to use
Agile methodologies while working with a large federal agency and a few other organizations. The
large federal agency project was most interesting because it was a complex
project. One thing I noticed right away was the level of collaboration used. The experience was very different from what I had been accustomed to. The Development team was large, but despite its size everything was well organized. Problems were discussed
daily and solved before the next day’s meeting. It was great to get experience
in supporting a large project using Agile. But I still was not convinced user stories were better. This is one key reason it has taken some time for me to actually write about them.
After spending years writing use case specifications and software requirements specification, I wasn’t sure user stories where a good idea. But after working with them over time I began to see their value. I wanted to use this blog article to discuss the format I use to write user stories and present some examples, which I hope are useful.
In this example, we would expect the user story conversations to include discussions not only on customer orders but also products. This is useful because a customer cannot place an order without a list of products or services to order from.
From a Developer perspective (i.e., Database Developer or Software Developer) writing user stories that are concise and value-driven strengthens the quality of the requirements and, ultimately, the product being built. The following example includes a user story that associates software problems with trouble tickets. Notice in the Notes section taken from the conversations, “problem description” is discussed. Also notice the user story description provides insight to the workload and the business users’ objective for the user story (i.e., “they want the system to help them process new tickets in a timely manner”, which results in alerts being added).
To make user stories easier for Developers to work with, I embed the use case in the user story. In the following user story [employee] is the role, [submit trouble tickets] is the use case or the “what” and [to describe software problems] is the why. This approach helps developers transition into user stories more easily. They always know to look to the middle of the user story to extract the use case. And, they know the role is at the beginning of the story with the why at the end, as applicable.
The above user story is ready for development. It includes the details necessary to convey the functionality required for the Product Owner and Development Team to all agree on what “Done” means.
Notice this user story is assigned 8 story points. To add story points, the Development Team used the Fibonacci sequence (1,2,3,5,8,13,21,34,45), which when diagrammed shows an upward curve indicating an increase in complexity as the numbers go up . They gave this user story 8 story points. This story serves as the baseline to assign points to all future user stories. More complex user stories will consistently have a higher number. User stories with the same complexity will be assigned the same number. And, user stories that are less complex will be assigned a lower number.
Hopefully you will find this information useful and it will shorten your workdays and make your career a bit more brighter.
After spending years writing use case specifications and software requirements specification, I wasn’t sure user stories where a good idea. But after working with them over time I began to see their value. I wanted to use this blog article to discuss the format I use to write user stories and present some examples, which I hope are useful.
Value-Driven User Stories
User stories do a good job of presenting requirements in a way that is more concise and easier to understand. Over the past couple of years I have focused primarily on writing value-driven user stories. This means I try to make sure every aspect of the user story adds value in defining the software functionality as it pertains to user expectations. I think facilitating a meeting does mean asking questions to help users think and talk about what they want. But I also think the BA or SA has some editing to do to make sure the content is as useful as possible. For example, I could write a user story that says: "A salesperson wants to add an order to meet customers’ needs." I’ve included the role (salesperson). I’ve also included the what (add an order) and the why (meet customers’ needs). However, the “why” can be written to add the same level of value as the “who” and “what”. If I rewrite the user story, it might look like this: “A salesperson wants to add customer orders to track products purchased”. This user story ties orders directly to products purchased.In this example, we would expect the user story conversations to include discussions not only on customer orders but also products. This is useful because a customer cannot place an order without a list of products or services to order from.
From a Developer perspective (i.e., Database Developer or Software Developer) writing user stories that are concise and value-driven strengthens the quality of the requirements and, ultimately, the product being built. The following example includes a user story that associates software problems with trouble tickets. Notice in the Notes section taken from the conversations, “problem description” is discussed. Also notice the user story description provides insight to the workload and the business users’ objective for the user story (i.e., “they want the system to help them process new tickets in a timely manner”, which results in alerts being added).
To make user stories easier for Developers to work with, I embed the use case in the user story. In the following user story [employee] is the role, [submit trouble tickets] is the use case or the “what” and [to describe software problems] is the why. This approach helps developers transition into user stories more easily. They always know to look to the middle of the user story to extract the use case. And, they know the role is at the beginning of the story with the why at the end, as applicable.
Test Cases
Test Cases are a great way to confirm user requirements have been met. The following capture shows the test cases associated with the “As an employee I can submit trouble tickets to describe software problems” user story.
Initial Task List
During the Sprint Planning Meeting, the Development Team can identify all of the tasks associated with development. The System Administrator should also document any items he/she must complete for development to commence and move forward. If a Database Developer and/or Data Analyst is part of the project these individuals should also add items to the list. Once the task list is created individuals can volunteer for the work they want to complete or the work can be assigned by a team lead, whichever is applicable.The Barriers/Action Items List
As the Development Team works to complete the iteration items for a Sprint, problems always arise. One way to manage daily problems is to keep a Barriers/Action Items list. The list should be accessible to everyone at all times. It can be updated during the daily standup as well as throughout the day. If SharePoint is used to manage the Barriers/Action Items list, the Product Owner, Project Manager and team members can all subscribe to alerts to be notified as new items are added. This way if you can solve a problem, you hear about the problem as soon as it is recorded.
