As an aircraft maintenance planner, I want to create individual orders for repairs of aircraft so that a work order can be charged against a job order number.

In this entry, we continue to address the questions I received during a recent webinar on User Stories. I felt that it was important to share and expand on the answers that I included in the webinar with a broader audience.  Today’s question:

“I would like to see some sample user stories in infrastructure projects such as network migration or upgrade, storage provisioning, or server provisioning.  I think storage provisioning would be a little bit complex due to hardening and other security requirements.”

People often think that user stories only make sense for projects and applications with customer facing user interfaces (UI), but not for backend systems or technical requirements. It is easy to find examples of user stories for UIs on the internet and far harder to find examples of stories for more technical or operational requirements.  That is not because user stories are not useful in these scenarios, but rather they are more difficult for broad audiences to understand.

User stories (format: “As a <persona>, I want to <goal> so that <benefit>.”) User stories are narratives describing who is interacting with the application, how they are interacting with the application and the benefit they derive from that interaction. The term that tends to trip user story users up, trapping them in a UI only point of view, is the term ‘user.’  The definition of user that the International Function Point Users Group (IFPUG) uses is an ISO-influenced definition that avoids this problem.  It is: 

Any person that specifies functional user requirements and/or any person or thing that communicates or interacts with the software at any time.

Using this definition, the universe of situations that can be addressed through user stories can include technical and operational users. The construct of user stories can be leveraged to identify and track most any project or application requirement.

Examples of real life user stories including network, technical, project risks and standard user facing functionality are shown below (used with permission, but modified to obscure the organizations involved).

  • As a network administrator, I want the “Big Telecom’s” SIP circuits installed in the New York data center so that alternate paths can be established for the phone system.
  • As the organizational security officer, I want firewalls installed on all VOIP circuits so that security is improved.
  • As the office manager, I want to ensure that risk of equipment breakage during shipping does not impact the phone system cutover so that we don’t miss call center SLAs. (A risk story)
  • As an aircraft maintenance planner, I want to create individual orders for repairs of aircraft so that a work order can be charged against a job order number.

The user story construct helps project teams remember both who is interested in the story (persona or user) and the benefit that will be derived from delivering the story (value). The Three C’s of user stories: card, conversation and confirmation can and should be leveraged for all types of requirements because the format of a user story provides focus.  Perhaps it should really be “Three C’s and One F” – or does that feel too much like a bad report card?

Note:  The question does present a number of nuances that does not relate to user stories such as the need to ensure hardening and security that are not needed in typical UI user story.  We will tackle those nuances tomorrow.