During an Information Technology project there are many times when the Team needs to do some research, analysis or design work prior to starting the actual coding work. In these cases we want to capture these activities and work, as ultimately they are adding Value to the Team and providing information that allows the Team to make progress.
In this Blog Article we will discuss what is a Research Story in the context of an Agile Methodology. When to create these types of User Stories and how to capture their Value to the Team. Additionally, we will discuss why we would want to do this, as opposed to not. Enjoy!
The whole purpose of an Agile Research Story is to conduct an investigation, analysis, and come up with potential options or a design / architectural approach to a problem.
The format for a Research Story is slightly different from the Traditional phrasing. Here are several examples of how you might write the Initial Summary Statement for a Research User Story:
As a Software Architect / Technical Lead, I need to research the following technologies, so that we can determine which approach is the best to take and present these options and our analysis to Management.
As a Software Architect / Technical Lead, I need to create a Design Pattern for the Micro-Services Layer, so that the rest of the Software Development Team can use it in developing the various Microservices and End-Point Service Calls.
As a Database Designer, I need to create an Entity Relationship Diagram that describes the various relationships and table structure in ____ Module of the Application, so that the Development Team can understand how things should be structured and make adjustments to the initial design diagram as needed.
As a Product Owner / Business Analyst, I need to review the following documentation ____ , so that I can start to define and create the Epic Stories and Product Roadmap for the Team.
As you can see, there can be many different formats. But in every case, you are defining:
Every Research Story must have one or more Artifacts or Outputs that are produced from the activity, otherwise, “Why are you doing this Research?”
From the above examples, there are many potential Artifacts or Outputs that either the Team or Others, such as Management need or will use at a later date. These can include, but are not limited to:
Very similar to how you estimate a normal User Story, you also want to use Software or Story Points to point your Research Stories.
The reason why you want to do this, is that you are producing something, which will ultimately lead to a Finished Product. It really is no different than a Manufacturing Engineer creating specifications for a complex machine. Without those specs and designs the team won’t be able to build the machine. Even though in this case, it is not “Working Code”.
And just like with normal User Stories we want to evaluate each of the Research Stories based on the complexity of doing the research, creating the artifacts, and editing (QA Testing) the artifacts.
Remember that for Story Points we use a Fibonacci Scale to measure the complexity of what we are creating (the output or artifact).
0, 1, 2, 3, 5, 8, 13
If an item is greater than 13, then it needs to be broken down into separate Research Stories, because there is no way to complete the work in a normal typical Sprint.
This is the Number 1 Rule on every Software Development Team. If you create or design something, then someone else needs to check your work. The main reason behind this is that often when we build something we won’t notice the flaws in our design and overlook potentially better approaches to the design.
While I'm pretty smart, I always assume that I missed something when creating a design, architecture, a presentation, or even a Blog Article like this. So, I always have someone check my work, edit it, or make suggestions.
In 2015 I was doing a contract project for GM in their Customer Care Aftermarket Division, and designing a fairly complex User Interface for both their Employees and Dealers. I created what I thought was a pretty solid User Interface for the new Module of the Application. However, our lead Business Analyst on the Team reviewed it and came up with an even better and more simple design. It was actually brilliant on his part, and would reduce our amount of coding work by probably 10% and make it much easier to use.
At first he was embarrassed that I might think he was questioning my work. But I was like this is excellent, you took my work and greatly improved it. That is fantastic! After all that is the whole idea of having someone else QA your work, to improve upon it and make it better.
While I am a HUGE proponent of Lean Information Technology and Agile Methodologies and have been using them for over 2 decades now, I also believe strongly that you have to adapt the methodology to fit your particular situation. This way it works best for you and your teams. After all one of the major Tenets of Agile is the concept of Kaizen - or Continuous Improvement, where as a Team you review what is working, what isn’t, and what changes do we need to make.
Unfortunately, I think all of us have encountered individuals who take a more Purist Perspective of Agile. For example, they will say that the Term “User Story” can only be used to define specifically what an actual User is doing. And that it cannot be used for anything else. I think this is very short sighted, as then it would not cover other components that any Software Development Team has to build into the application, where no User is involved:
I bring this up, because you will meet individuals who have a very strict interpretation of Agile, and as Executives you need to be able to counter this and help them expand their perspective. Because at the end of the day, you need to track and measure the progress on all of these other items as well.
In this Blog Article we have discussed:
We hope that you have enjoyed this Blog Article and found it valuable.
Thank you, David Annis.
