Getting My Firs...Getting My First User Story in a Corporate Project
Getting My First User Story in a Corporate Project
Priyanshu Chaurasiya
About 1 month ago
A few months back, I joined Coforge as a Graduate Engineer Trainee, and after completing my initial training in Angular and .NET, I got aligned into the Adecco project as an L2 Technical Support Analyst. My daily work mainly included handling incidents, tasks related to end-user issues, and resolving them.
It’s not like support work is bad or that I wasn’t learning things there. In fact, I am learning a lot, especially about the functional side of the application, how enterprise applications actually work, how users interact with systems, how issues are analyzed, and many other things which are very important in real projects.
But somewhere, one thing always felt missing.
Over the last few years, I had put a lot of effort into becoming a developer. Coding, building projects, debugging things, learning technologies, that was the path I always saw for myself. And while working in support, I always wanted to contribute on the development side too. I wanted to write actual production code, work on logic implementation, and experience how development happens inside a real corporate project.
And finally, I got a chance.
This blog is all about that experience, getting my first user story, working on it, handling fear, learning completely new workflows, and slowly stepping into the development side of the project.
So hello and welcome. I am Priyanshu Chaurasiya, and this is the story of my first user story. So get your cup of tea ready, because this one is more of a real experience than a technical blog.
A Random Late Evening Call
Honestly, the story of getting the user story is probably more interesting than the story of actually doing it. It was a usual workday. I came back from the office to my hostel room, tired as normal, and I hadn’t even changed my clothes yet when I received a Teams notification asking me to join a call.
Comments
Have something to share?
Join the conversation by signing in below!
I joined.
Inside the meeting were my Senior Manager, Senior Technical Lead, and Scrum Master. The moment I saw everyone there together, I panicked.
As a fresher, sudden calls with senior people already feel scary, and this one felt even more serious because I had absolutely no idea why I was called. In the calls I was asked questions like Priyanshu, what are you doing ? What’s the progress on the code setup ? Are you serious about doing development ?
At that moment, I genuinely didn’t know what was happening. I was nervous, confused, and honestly a little scared too. But sometimes life becomes interesting exactly in those moments where you feel the most uncomfortable.
And that same evening, I was told something that changed things for me a little. No matter what happens, by tomorrow morning all the applications should be running locally on my system. And along with that, a user story was assigned to me.
Late Night Code Configuration
As I mentioned earlier, I always wanted to contribute on the development side. Because of that, I already had the project code setup on my system. In fact, I was probably the only person from the support side who had done that setup. But there was a problem. Due to some access-related and configuration issues, the application was still not running locally. And now suddenly, after that call, I had a deadline. The applications had to run by the next morning.
So that night, I again started trying everything possible. I tried figuring things out myself, used Copilot, searched around, tried understanding the setup flow, but since I had never really worked on large .NET applications inside Visual Studio in a corporate environment, many things were completely new for me.
I had no idea how the repository flow worked there, how to pull the latest code properly, how configurations were managed locally, how shelvesets worked, and many other things. After struggling for a while, I finally called one of my teammates, Ansh. He was actually the person who had originally helped with the code setup earlier too, so I directly reached out to him again. And honestly, that call saved me.
He stayed with me till late night and patiently helped me through everything, getting the latest code from the repository through Visual Studio Azure DevOps, configurations, local setup changes, database strings, keys, shelvesets, and many other setup-related things.
Finally, after hours of trying things, the applications started running locally.
Once everything got aligned and the application finally started running locally, I actually looked properly into the user story. I took help from my team lead and teammates to understand the flow and requirements properly because many things were completely new to me from a project process perspective.
The user story was mainly related to fixing a synchronization issue between Outlook Calendar and our in-built application calendar. I won’t go very deep technically because of project privacy guidelines, but the overall process itself taught me a lot.
Since calendar-related operations involved third-party vendors and integrations, I started reading their documentation, understanding the flow, tracing the issue, and figuring out what exactly was causing the problem.
And slowly things started making sense. I analyzed the issue, implemented the required logic changes in the code, tested things locally, and finally got the functionality working.
Working In A Corporate Project
Obviously, this was not the first time I was doing development or pushing code changes. I have built many personal projects before, used Git version control, pushed commits, raised pull requests, debugged issues, and all those things.
But this experience felt completely different. Because this time, it was not just coding. It was about following a proper development process. There were analyses, task creation, local testing, changesets, code reviews, approvals, check-ins, and many small workflows in between that together make enterprise development look very different from personal project development.
And many things were completely new for me. Azure DevOps boards, sprints, changesets, task management, code review flows inside Visual Studio, these were things I had either never used before or only heard about. Even the things I already knew felt different in a real project environment.
More Gates Opened
Looking back now, that late evening call was full of fear for me. As a fresher, I genuinely was not mentally prepared for that sudden pressure, especially in front of senior people. But strangely, that moment turned out to be good for me.
That night, I got my first user story. And after that, slowly more doors started opening. I started getting more development-related work, more user stories, more analysis and debugging tasks related to code, and gradually I started becoming more involved on the development side inside the project. And honestly, that feels good. Not because everything changed overnight. Not because suddenly I became an expert developer. But because I finally got a start.
I think I’ll end this blog here before stretching it too much. This was simply my experience of getting and completing my first user story, stepping into development work inside a corporate project, learning new tools and workflows, and slowly becoming comfortable with things that once felt overwhelming. It may sound like a small thing to many people, but for me, it was an important experience. And maybe this is just the beginning.
Do let me know your thoughts, feedback, or your own similar experiences. And also tell me what kind of blogs or topics you would like me to write about next.
Recent Comments
No comments yet, Start the conversation!
Getting My First User Story in a Corporate Project - Hey Sainty