December 16, 2020

Agile Nearshore Development Research Stories

What is a Research Story in the context of an Agile Methodology. As a software development company our services will increase your technological capabilities.

Executive Summary

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!

tech company

What is an Agile Research Story

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.

Research Story Form

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:

  • Who (Role) is doing the Work
  • What Work they are Performing
  • And What is the Output or Deliverable

tech company

Artifacts - Acceptance Criteria

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:

  • Buy vs. Build Analysis and Presentation
  • Coding Standards Documentation
  • Design Pattern for Microservices
  • Entity Relationship Diagram
  • Epic Stories Defined
  • Presentation to Management on the Pros / Cons of Potential Technical Approaches or Options
  • Product Roadmap / Release Plan with Phases
  • Process Flow Diagram

software company

Software or Story Points

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.

Fibonacci Scale

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.

software points

Never Quality Assurance (QA) Check Your Own Work

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.

user interface design

True Story - User Interface Design for General Motors (GM)

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.

software development company

Kaizen vs. The Agile Purist Perspective

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:

  • Integrations between Systems
  • Database Table Structures
  • Micro-Services Layer
  • Security
  • Development Operations
  • And naturally Research Stories, as well as others

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.

IT tech company in USA


In this Blog Article we have discussed:

  • The need for Research User Stories
  • What format the Stories may take
  • Acceptance Criteria and Artifacts that are produced
  • How to Point the Research Stories
  • And how to handle potential Objections from Agile Purist

We hope that you have enjoyed this Blog Article and found it valuable.

Thank you, David Annis.

Case Study from Arkusnexus
David Annis
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles. He assists our Sales, Marketing, and Operations Teams on critical initiatives.
RSS feed
Subscribe to our feed
Back to More ContentMore From this Author

3065 Beyer Blvd B-2
San Diego CA 92154 - 349

mind hub tijuana