As a Technical Business Analyst, I have at times needed to tweak my approach and templates to create an effective story.
I have found the below templates useful when I am working on a technical story, a defect or a tech spike.
a) Tech Story Questions/Template
As a user/system I want to be able to so that I can
I have found this agile way used universally to be very helpful to give a one line insight into what we are setting out to achieve. As a Tech BA at times I have struggled to frame it in this format. However putting in the effort to word it right brings out the essence of the story. It makes it readable and understandable for tech and non-tech stakeholders. It sets the tone of the story to discuss it in further detail.
Summary of what we are trying to achieve
Elaborating and giving a context around the story gives the audience an idea of why we are trying to achieve this. This can be worked on by answering questions like: What initiated this story? What problem is this story solving? What value is the story adding?
What is the approach we plan to take?
This question is to make the development/tech team brainstorm about how and what needs to be done to achieve the first statement of the story. This conversation is imperative and forms the crux of what and how we will deliver. This should be a free flowing conversation with the tech team and every input should be considered and validated. Even if it looks like it is a development intensive story ensure everyone from the squad is part of the conversation. It ensures that we have covered the story from all angles and we haven’t missed out things from a testing or a non-functional point of view.
What conversations do we need to have and with whom? What skills do we need to complete this?
The above conversation will lay the foundation which will highlight what skills or questions must be answered to complete the story. Do we need more detailed design? Do we need collaboration with downstream teams? Are there any configurations that we need to consider? Is there a skill we need that we do no currently have?
What are the known unknowns in our approach?
(Potential risks and unknowns or blockers expected)
This is an important parameter of the story. Are we working with known unknowns or assumptions or constraints? Does our approach come with any risks that need to be highlighted or escalated or exempted? For example, we are unable to mask all customer data in non-prod, since our automated test cases need customer data. These questions can uncover risks. They shed light whether we need to fix our test suite or what workaround do we need to do with customer data in non-prod.
How can we confirm this is working?
Given <> when <> then <>
This format works best to create testing scenarios for the story. This format in conjunction with the first line of our story gives us a structured format to write tight test cases or acceptance criteria. This should also include non-functional parameters: performance, reliability and security.
Documentation Link (if any)
Yes, it is a good practice to avoid unnecessary documentation. However, in my experience I have seen a few tech stories needing documentation.
How big is this piece of work?
Complexity sizing works best in an agile world. There are numerous methods out there that can be used. Fibonacci series and t-shirt sizing are the most commonly used in my experience and easy to grasp.
b) Defect Story Template:
Current Behaviour –> what happens now
Expected behaviour –> what should be the correct behaviour
Impact–> what is the defect impacting
Steps to reproduce –> Do we know how to reproduce the error? Is the defect environment specific? If we are unable to reproduce in a specific environment, what is the configuration or data difference between the two?
Root cause analysis and Steps to fix should ideally be the output of this story/epic.
c) Tech Spike/POC Template
Do we have multiple approaches?
Tech stories can have varied approaches and the output can be unknown. List down all the approaches and brainstorm them.
What approach are we taking?
As a spike for one sprint consider the approach which seems viable, efficient and the one which is preferred.
Do we need to time box it?
I am an advocate of time boxed POCs. After the end of the time the team can discuss the challenges or issues or wins and then decide if another POC is required.
What are we expecting to see at the end of the POC?
It is crucial to set the expectations of the POC at the beginning. A POC need not turn into a complete implementation. A POC is to uncover the do ability of an approach or the challenges of that approach.
Along with these it helps to keep the INVEST (independent, negotiable, valuable, estimable, small, testable) or SMART (specific, measurable, achievable, relevant, time-boxed) techniques for user story quality in mind. I have always found creating an Independent tech story which can be done in a sprint to be a challenge. However, working with a method gives a structure and similarity to the stories. This is advantageous for the project and everyone on the team gets around to working with it. Having said that method used should work for the team and not against the team.
Views: 171
