What is a user story?
A user story is an agile development term that describes a product feature from the perspective of the end-user. User stories help product managers clearly define software requirements so the development team understands the desired outcome of the new functionality.
Why we need to understand the approach a user story
In any MNC there is a huge chance that you are not able to deliver your work on the estimate time. Sometimes we feel so pressurized and tired. But, is there any solution for it? if yes how can we achieve this? so, before moving to the solution directly let us understand this problem root cause. With almost all the individual or professional working in MNC, this problem arises due to lack of planning and no proper user story management. Now we know the problem so, let’s move towards the solution step by step.
What are the basic terminologies involved?
Before presenting this post to the intended audience I would like to familiarize the audience with the following terminologies:
User story
Informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end-user or user of a system.
Deliverables
A software product, a server upgrade, or any other building block of an overall software system.
Story points
A unit of measure for expressing an estimate of the overall effort that will be required to fully implement a piece of work.
Integration testing
Phase in software testing in which individual software modules are combined and tested as a group.
Unit testing
Level of software testing where individual units/ components of a software are tested.
E2E testing
Test from the end user’s experience by simulating the real user scenario and validating the system under test and its components for integration and data integrity.
Bandwidth
Resources(here time especially) that are required to perform a specific task.
Estimates
The process of finding approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable
Suggestions for managing user-stories
I have tried a few steps to manage the user story to be delivered and giving out estimates to complete a user story. I expect the audience to know the fact that this is an evolving experience and will continue to have a bit of twerk and modifications as we go forward.
1. Work Estimation: Break your work into subtasks. Let your team leads know how you’re going to manage your user story and deliver it. Also, ask if anything is missing or anything could be done even better.
2. Understanding the output of the user story: Before you implement anything in code it is very important to know how your implementation will contribute to the value of the software solution. Don’t hesitate to go ahead and ask your leads, product owners, or proxy product owners that how they are expecting the functionality to show up. But before reaching out to anyone do read the descriptions and other assets and artifacts described in the user story. Try to visualize the roadmap of the implementation. Write it down in a paper and think of it with the utmost clarity as you can. Don’t do the mistake of judging yourself even if you have to write down each and every thought process of the implementation as your implementation and end product functionality will be judged and not the thought process you have taken to deliver it.
3. Defect resolving: Even though your ego might make you feel that whatever you have implemented is just awesome and flawless and there is no way that a defect might show up but you always need to keep buffer for defects as well. I have seen that defects do show up and that is quite natural.
4. Technical challenges – some deliverables might require you to learn some new technologies(eg if you have been working on the backend and you need to work on some UI related story which is having some jQuery implementation and you don’t know anything about jQuery as such) then the estimation of the jQuery knowledge gaining must also be taken into consideration while providing estimates. Also, learn as much is needed since you have tight deadlines.
5. Testing – the estimates should also have a slot booked for unit testing of your stories where you can run through all the various scenarios which are going to be impacted by your implementation as well as also test the existing scenarios to see whether they are working correctly or not.
6. Look into other related stories – Keep in mind if you are effectively able to manage the former points then only try to proceed with this point. You should also be looking into the other stories which are related to the story assigned to you. This will help you better visualize in integration testing and E2E testing.
On that note, I would like to say that whatever I have shared in this post is an outcome of around 8-9 months of working in a production-grade project (which is obviously expected to have tight deadlines ). All these points shared are not mere conclusions but will continue to evolve over time as we gain more and more experience and do more and more mistakes.
Do you want to read more
- Interview Preparation for SES Infosys: click here
- Things to learn before joining Infosys click here
- Complete blog about SES Infosys click here
- Salary breakdown and salary slips of SES before and after training click here
- Mern stack stream complete flow explained click here
- My experience in Infosys as a System engineer specialist click here
DISCLAIMER: I would not at all recommend following these points strictly, of course, this will take time to get into your work cycle. I only intend to outsource my experience to help those who are constantly struggling with time management in story delivery.
One more thing, with time you will surely learn where you lack in your performance and you will then start improving after acknowledging your inefficiencies.
Till then keep coding, keep delivering, and stay well!