As I started out in Agile software development, as a lowly intern, I was bombarded by jargon. Terms like ‘scrum’, ‘sprint’, ‘velocity’, and ‘TCC’ came flying at me right from the get-go. With hardly time to create a mental dictionary of these new terms, I found myself in meetings with product owners, a senior developer, and QA person, all talking about how to implement the current ‘user story’. Having little to no background, I more or less mentally checked out until the meeting was over and we had a list of things that actually needed to be done; which meant I could now go and do what I knew, write some code.
Being the intern, I never had much insight into where these magical statements of desired functionality came from. All I knew is that when I was done with my current work, another developer and myself would pull the next user story from backlog into TCC, and schedule a meeting like the one above. I didn’t give any thought as to how these nuggets of work came about; I only viewed each as the next problem to tackle. And I will admit that I was quite happy in my ignorance. Work was full of doing the thing that I enjoyed, without much distraction.
Skip ahead a few years, and I now find myself on the other side of that coin. Often my days are filled with meetings, attempting to discern what it is a customer really needs; as apposed to what they think they need. This can be a very difficult time for anyone who is very technical in nature as functional users are not very specific in what they need. I mean, why can’t they just tell me how much remote file storage they need? or exactly what firewall rules they need put into place? It’s their application after all, they should know how to make it work! And really I just want to get to coding as soon as possible.
Unfortunately the world is not as such, and we need a way to capture what a customer WANTS not what they NEED. And this is where the user story comes in. User stories are a great way to capture the function that the customer is needing to perform. For example: “As a user I need a place to store uploaded pictures to include in reports later”. Sounds simple, has a straight forward objective, and is easily understood by everyone involved. It does not give any indications as to where to put the pictures, what format the pictures will be stored in, or how many a single person may be able to store. These are all details to be sorted out before implementation. Because we aren’t bogged down at every step by all the details, the project team can spend their time figuring out what they want their program to do. Which is great, because who really knows how an entire system is going to be implemented until you get in and start making it anyway?
The important thing about a user story is to capture WHAT the user needs to do, and WHY they need to do it. During the TCC these two parts serve as the focus for implementation, and getting them down in a clear form makes things much easier going forward. I’ve included links to some other resources below; which elaborate on this topic. Thank you for reading, and happy requirements gathering!
