How to best act on a user story
First of all let’s get clear of what I’m calling user stories. I mean the basic work item unit of modern software development. A set of acceptance criteria that will fulfill a business need for a digital product. With that in mind, I’d like to share with other software developers what I learned on how to best act on stories with my practice. Some of my advices in this article might make more sense for people working in teams.
Understand the purpose
Way before we open our IDEs or text editors and start coding, it is important to have a clear understanding of what is expected to be delivered with such story. It makes all the difference if we know, even before we start the implementation, how the customer is going to test it in homologation stages. Otherwise how would we really know if we are done with it?
Think about the business needs
Software developers don’t really deliver code or configurations. We deliver business value. Of course we sometimes need to stop, step back and work on tasks that are all technical in order to improve the software quality, but that is just something we have to do, not the purpose of our work. Our purpose is to make stuff possible for the users, even if those users are other developers or another software.
Don’t be afraid to suggest different solutions
Your story already came with a solution specification? Before going down the suggest road, it is nice to make sure it really is the best fit. Got a better idea just looking at it? Don’t keep it to yourself! Bring it to your architect/manager/team before spending hours or even days with a solution that looks overcomplicated or you don’t agree with.
Stick with the scope
We all know you have to try that fancy new feature of some library that you are very excited about. Or that new approach you found in that very nice post in your research on the subject. But does it really make any difference in the story purpose? Never start implementing something that is not expected before taking it to your team, otherwise you might just be creating more things to maintain.
Be quick to ask for help
Don’t be stuck in the same problem for hours straight. Put the issues you are having in words and bring it to your team. A lot of the times you might notice that you are lacking some context, and your issue is not really technical. And sometimes your issue is technical but some of your teammates have already dealt with it. Mature companies don’t expect developers to be heroes, but to communicate well.
Walk the critical path first
What is the user story really about? Make sure that need is addressed first. Is it an authentication page? So make it possible for users to authenticate first! It is better, for instance, to have a login system with a bad layout than having an awesome layout that does nothing.
Just test that sh*t
It is really terrible that we have to tell people to test their software in 2021, but sadly we have to. Like I said before: know how the customer will test it, and make some automated tests about it. I know functional tests might be hard or expensive to do, but at least make sure your software won’t break because of a minor code issue, it is the bare minimal.
With all that in mind, I also ask you to never forget what is the most important thing about software development: people! So have empathy with the people using your software. Remember how angry you got with that bug in that app you like to use very much, and think how people using your systems are feeling.
