In the world of software development (organized programming), user stories are popular. However, they need not be constrained to the world of programming. User stories can provide value in any IT project ranging from IoT to desktop configuration management.
A user story is a defined unit of development aimed at achieving a capability required by a given user. The user may not be a single user but rather a persona representing a collection of users or a type of user. The format typically follows:
As a [user persona], I [need/want/must] [do something/have something] so that [reason/purpose].
For example, a user who requires the ability to access the wireless network from the factory floor might have the following user story:
As an inventory manager, I need to be able to access the wireless network from the factory floor so that I can manage inventory from my tablet while in the actual work space.-A typical user story
In traditional IT projects and software development, we call these user stories requirements. However, the format of a requirement has the primary focus on the non-human function. For example, a requirement matched with the preceding user story may read:
Coverage must extend to the factory floor so that tablets can be used to access the wireless network.-A typical requirement statement
While this requirement is accurate (though it could use more detail), the user story version has that extra, practical, user-related information that can help the wireless designer/engineer make decisions during design and deployment. For example, the format of the user story, by nature, includes the “why” (so that I can manage inventory from my tablet) with the “what” (be able to access the wireless network from the factory floor). Note that the requirement statement only includes the what.
Of course, we could simply format our requirement statement to include the why, like this:
Coverage must extend to the factory flow so that tablets can be used to access the wireless network and update inventory on location.-A “why”-based requirement statment
However, the reformatted requirement statement (while better) is really just a non-personal user story adjusted to be a dry formal statement of requirement.
User stories can easily be extended into use cases when required. The major difference between user stories and use cases is in the details, literally. Use cases include more details such as:
- What conditions must exist for the user to take the action?
- What exact steps does the user take to perform the action?
- What alternate workflows are used to achieve the same end result?
I’m certainly not advocating for the remove of use cases in software development and other IT projects; however, starting with user stories adds that personal touch and the user stories can act as the guiding elements in decision making while the use cases can be available for that drill-down detail when required. Both is better than one, and user stories is better than none.
Finally, user stories can be mapped into logical workflows. User story mapping involves taking all the user stories and organizing them into logical categories that allow for simple development or implementation. Jeff Patton is well-known for promoting the concept of story mapping and you can learn more here: User Story Mapping – Jeff Patton & Associates (jpattonassociates.com)
Requirements analysis and documentation is an essential part of any IT project. When considering your next IT project, think about the use of user stories in place of project requirements to bring the personal element to the project and to ensure that the “why” behind the “what” is never lost.
-Tom