Author : Ajay Kumar Goyal
User stories management is very important in ensuring the right scope of work for a particular sprint and a series of sprints defining a release. In Agile projects, where the work items are so dynamic; the life cycle management of the user stories becomes even more significant and influential in defining the accurate need.
Here, I would like to share few process improvement points or the recommendations that I do in all of my projects. Different projects have different approaches and processes to keep a handle on the scope and to drive the right development and testing efforts of the requirement. The points that I am sharing below can be considered as a subset or additional points for reference. Ultimately, the goal is to drive the RIGHT quality on the RIGHT scope of work.
Let’s start….
- Depicting the user story life cycle as below:
- User stories are mostly written by the functional leads and business analysts involving both MSFT and the customer teams. These are then finally reviewed and approved or removed by the customer in the backlog of user stories.
- On the Approved user stories, based on the priority and capacity in the current sprint, the user stories are committed as the sprint scope by setting the state to Committed.
- When the work is actively started on the user story, the team sets the state of the user story to Active.
- The attributes in the user story template should be updated correctly and religiously to avoid any sort of confusion for the team on the scope and the status of the work.
- Post MSFT Dev and QA completes development and validation, the user stories are delivered to the customer for validation and closure. The customer updates the state of the user story to Closed post successful validation.
2. Feature Specific and Integration Functional User Stories:
Besides the feature specific user stories, the team should also focus on writing the user stories which will cover the integration aspects among the features being implemented within the sprint, across the sprints that is for the release aiming for E2E working of the application with no gaps.
3. No Development Implementation User Stories (Mostly Technical Tasks): All the development technical activities should be considered as Tasks and to be Linked to the functional user stories. Like-wise, all work required from QA, UX, DB and so on should be created as tasks and linked to the user stories so that we have the collective effort defined for the functional user story.
4. Changes to the defined Scope: New functional user stories should be written to track the new changes and to be taken up as a CR (Change Request).
5. Not anybody or everybody should create functional user stories: We need to have the functional leads and / or the business analysts from MSFT or the customer team only to create these user stories to avoid any kind of anomalies.
6. Planning Poker/ Estimating User Story Points:. This should be based on the collective discussion by the overall team considering the complexity, business impact and overall effort. Defining certain rules and conventions while estimating the same and continuing across the sprints. Ultimately, to gauge the velocity of work within a sprint and for a release.
7. NFR User Stories (Non Functional): There should be clear user stories defined for covering the non-functional requirements, the performance benchmarks, browser compatibility requirements, localization requirements and so on.
8. User Story Type: In many projects, it is observed that the technical tasks are also created as user stories. Better to create and define a new attribute in the user story template which defines if it’s a functional user story, technical or non-functional user story. Management of these user stories becomes easy and there will be no gaps.
The team should work with the defined scope of work and deliver RIGHT quality on the RIGHT scope.