Sections of this topic
User Stories & Documentation: Humanizing Project Management
I was reading about Agile and Scrum methodologies for project management when I came upon the term ‘Agile User Stories’. As an introduction, Agile is a methodology used for software development projects. It provides more control than just stepping through the analysis, design developing, testing, and implementing stages of a project as a whole. The Agile methodology breaks down each stage into subsets so that there is more communication, collaboration, feedback, and discussion as each stage is completed. The Scrum methodology (a subset of Agile) is where each piece of a project is worked on as individual tasks for more accuracy and control.
A User Story (a further subset of the above methodologies) is a single sentence that describes a particular task that needs to be done. This need will define a particular project. As an example, suppose a manager is having trouble finding certain information on an employee. The manager may write the following sentence: ‘As a manager, I would like to find employees with have not taken any sick days so that they can be given an award.’ That sentence or Agile User Story is then brain-stormed to understand what the manager is requesting and to discuss details as to how to accomplish the task. All subsequent ideas and solutions are noted and prioritized. The brainstorming sessions will also discuss items such as requirements, functionality, time, cost, tools, resources, due date, testing, etc., but not all in one meeting; each item is done separately and documented.
A User Story is not a Requirements Specification. The Requirements Specification is much more detailed and is basically an agreement that ensures that the client and the project managers are all on the same page. As a whole, it describes the project and outlines the client’s requirements and expectations upfront.
In comparison, a User Story is brief and describes what the user wants in one sentence. If a User Story is long or needs to be broken down further (e.g., as a manager, I would like to find employees who have not taken any sick or personal days so that they can be given an award), then it is known as an ‘epic’. The ‘epic’ will then be broken down into simpler sentences for clarity (e.g. as a manager, I would like to find employees who have not taken any sick days so that …. And as a manager, I would like to find employees who have not taken any personal days so that …). In other words, a ‘to-do list’ is created. This list is known as a ‘product backlog’ and will be prioritized and managed by a product/project manager or technical writer. During various stages of the development, more User Stories (‘to-do lists’) will be created either by the user, developer, or manager.
Are User Stories useful? Some say yes as it drives or communicates what a client wants and sets the stage for accomplishing individual tasks to complete a project, but others say that without the Requirements, Functional, or Technical Specifications, it is difficult to see how the finished product can be completed. No matter which methodologies are applied or what form of documentation is created, the written material should be able to explain in a concise and clear manner what was requested, how to accomplish it, and be focused on getting what the customer needs and that is what is important.
