From Requirement to User Story with Cloud ALM
SAP’s strategy for future SAP implementation and migration projects is clearly defined: This can be done efficiently and sustainably with SAP Cloud ALM! blue.works shares this opinion. For this reason, the following blog outlines how to get from requirements to user stories. How we came from the process scope to the requirements backlog is described HERE.
The example: Transformation project for S/4HANA private edition
The following explanations are based on an S/4HANA transformation project, not exactly specified whether on-premise, private or public cloud, but rather based on on-premise or private cloud. In terms of time, we are in the Realize phase of the SAP Activate methodology. The blog assumes that a project has already been created in SAP Cloud ALM, the requirements have been created, specified in detail, approved and assigned to the Realize phase.
The user story in its context
In order to place the user story in the context of a project and its requirements, the term user story is explained here. The amount of work (backlog) to be delivered by a project are the requirements. To deliver that functionality described in the requirements requires user stories. They describe how the requirements, defined by business, can be implemented through developers, IT staff, testers, etc. in order to realize a requirements.
Briefly defined: The user stories created from the requirements divide the work to be done in a project into smaller, comprehensible and achievable tasks.
The relationships between the user story and other documents
To further explain the context of a user story, the following graphic shows the relationship of a user story to other documents in SAP Cloud ALM.
The relationships of the user story to the process and the process hierarchy
The following graphic concludes the overview of the context of a user story by showing how a user story connects to processes and the process hierarchy.
Holistic traceability
The user story is another element used after the project, the scope, the solution scenarios, the solution processes and the requirements. This increases the complexity somehow. However, it can be seen from the above diagrams that almost every element is linked to each other. This creates a holistic traceability through all elements, which offers incredible added value in complex projects.
Who creates user stories?
Strictly according to agile theory, the product owner would create the user stories from the specified requirements. In practice, SAP projects sometimes look different, as in the area of SAP one does not always work in an agile manner. It often happens that developers or consultants create the user stories themselves and enrich them directly with the necessary technical information.
What happens in which status?
The following graphic shows the three most important statuses of a user story. In addition, the two statuses “Locked” and “Not relevant” are also available but these are not discussed further here.
User stories with subtasks
To subdivide a user story even more granularly, it is possible to create subtasks for each user story with a 1:n relationship. The degree of fulfilment of the subtasks can be seen directly in the header of a user story.
The content of a user story
Again, strictly according to the agile theory book, the user story should be recorded in one sentence in the format “I as [ROLE] want [FUNCTION] to [PURPOSE]”. Again, things look a little different in practice. As it is a free text field, the structure of the content can be freely selected. Items such as “Description”, “Comment” and “Definition of Done”, for example, make sense.
Three tips from practice
The title of a user story is mandatory. As the relationship between requirement and user story can be 1:n, it is advisable to give the title of the user story a prefix. SAP Cloud ALM does not currently offer a filter option on the Tasks app to search for user stories by the assigned requirement. Get in touch with us and we will show you a small workaround to make it possible.
The usage of subtasks can make perfect sense. If we look at the relationship between requirement – user story – subtask, this is 1:n:m. This quickly results in a large number of subtasks, which can (but does not have to) lead to confusion. It should also be mentioned here that subtasks are only directly connected to the user story and not to the requirement.
Since in practice it is not just a single product owner who creates user stories, but developers and consultants as well, the user stories are probably created with very different content structures. To prevent this from happening, it is advisable to store a template for the creation of user stories. Whenever a new user story is created, the template can be used with a corresponding predefined structure. This helps to consistently check the user stories against the “Definition of Ready”. How to either edit or delete a template user story is somewhat hidden in Cloud ALM. Get in touch with us and we will be happy to show you this and much more.
Conclusion
To summarise, SAP Cloud ALM offers a clear and efficient strategy for bringing SAP Activate from theory into practice. With SAP Cloud ALM, with SAP Activate, with the predefined best practice content from SAP and also the Fit to Standard approach, S/4HANA transformations become more efficient and transparent and do not have to start on “white paper”. The structured approach to create a requirements backlog and the further subdivision into user stories, as explained in the blog, emphasises the importance of careful planning and implementation of the Fit to Standard – workshops. Keep the important steps in mind and look forward to future blog posts that will lead your project to success.