Crafting User Stories That Agile Teams Will Love

A popular term you will come across when working in agile is the “user story.” For the uninitiated, a user story is a technique of expressing software requirements in a specific format, usually:

As a < role of user >, I want to < perform an action >, so that < goal of user >

This adds more detail and description, and it’s sure to include the real need of the user when expressing the requirements.

For agile teams, user stories are a typical way to begin a conversation about a feature. But issues arise when we stop adding more beyond the one-line user story format. Most agile teams are crippled by incomplete, ambiguous and vague user stories that lack depth and details.

In my experience, there are some ways we can ensure that the user stories we craft are usable and valuable in all aspects. In my latest article for Gurock TestRail Blog, I talk about strategies to craft meaningful, understandable and valuable user stories for your agile teams.

We discuss INVEST Principle of User Stories, 3Cs of a User Story and how to learn from Experience of past sprints to improve your user stories. Read the full article here-

https://blog.gurock.com/crafting-user-stories-agile-teams/ 

Cheers

Nishi

The crucial guide to Software Testing for Project Managers

Being a Project manager you often need to take on new challenges and create guidelines for projects in a field you are not always familiar with.

You might have some experience working with a team of software developers, which gives you insight into the relevant testing disciplines. Or you may have directly come in as a project manager and need to begin understanding the process from scratch. Whatever the case may be, we are sure you already have enough on your plate. That is why I have gathered a few basic guidelines – both technical and methodological – to help you succeed in your new assignment as a test project leader!

My guest post for PractiTest is now up on the QA Learning Centre-

Dedicated to all PMs – here I discuss the Software Testing 101 making this a guide to all PMs to all things crucial in test process management. Read More..

https://www.practitest.com/qa-learningcenter/thank-you/software-testing-guide-project-managers/

state of mind

Do give it a read and share your thoughts!
-Nishi

 

‘INVEST’ing in good User Stories

User stories are the requirement specifications in their simplest form. Methodologies like Scrum use User story format to express the functional requirements of the software to be developed as –

As a <user persona>, I want to <do the action> so that <need of function>

This creates a deeper understanding of the behavior from a user’s perspective along with the business need and reason for the function, thus making the development of software easier.

But writing effective user stories isn’t as easy as it sounds. There are a lot of questions to be answered, like which functionality is one user story and which is too big and needs splitting up; what is the true sense of the user story; how to best express the functionality in words; which user personas are to be considered etc.

Getting the user stories right is an essential step to success of the sprints in agile, and for the teams struggling with it we have the INVEST principal as a guideline to be followed. This principal gives the attributes of a user story to be considered when writing and defining them so that they can make a robust foundation to our product backlog. Let us look at the principle in depth –

I – Independent

Means that each user story must be Independent as a functionality and be deliverable

N – Negotiable

Means that the user story be negotiable in terms of implementation, which necessarily means that the implementation details or ‘how’ to do the functionality must not be specified in the user story. User story must be business need and customer experience story.

V – Valuable

Means that the user story must create value for the customer. We should be able to see the reason and way the function will be valuable to the customer and this can be gauged by direct communication with the stakeholders, and can also be quantified in terms of ‘business value’ that we can associate with each story.

E – Estimable

Means that the User story must be clear and concise enough so that we can estimate the amount of work required to achieve it with accuracy. Any unclear parts, missing information or discrepancies must be clarified before we can finalise a user story to be taken up for development.

S – Small

Means that each user story must be a small chunk or slice of work. The development of one user story must be doable within one sprint and hence anything bigger than that would need to be further split down.

T – Testable

Means that each user story must be testable as a feature and have a unique new function get added to the product.

Letter Meaning Description
I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
V Valuable A user story must deliver value to the end user.
E Estimable You must always be able to estimate the size of a user story.
S Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable The user story or its related description must provide the necessary information to make test development possible.

Keeping these points in mind when designing and formalising our team’s user stories will ensure that the sprint runs smoothly without unforeseen scenarios, glitches in implementation due to unclear requirements and re-work due to frequent changes.

Have more questions? How to achieve this?

Stay tuned for the next article where we will look at the steps to achieve the best user stories.

Happy Testing!
Nishi