Write your user-stories with an incremental and iterative approach

user stories incremental and iterative
user stories incremental and iterative

It is not always easy to find the right timing to write your user-stories to maximize their creation and minimize the loss of time. I will give you a first vision to gradually approach a more efficient model.

The proposal that I will make in this article is not to follow at 100%; I present it to explain the implementation of an incremental and iterative approach on the functional part of the product. Do not hesitate to create your own steps of maturation and adapt the proposed timing according to your context.

The incremental and iterative approach to write US

This incremental and iterative approach don’t applies only to the development but also to the backlog creation. It’s a mistake to try to prepare your user-stories completely some weeks in advance. You will meet two major problems:

  • Loss of time on the work done if the user-story is abandoned.
  • The apparition of the frustration for the PO; he could avoid to change  the scope voluntarily.

We have to give the chance to the product to have an agile scope.

For that, do not hesitate to set up a workflow of user-stories maturation with the good timing between each steps. Here is an example of a possible workflow (be careful each team will have their own workflow):

workflow to write an user-story
workflow to write an user-story
workflow écrire une us

The goal is to increment the user-stories of elements step by step during the life of them.

If we take the example of the workflow presented above, here are the key steps of our US and the timing that we will associate them.

 

1 / A general vision with a Story Mapping

When we have already done a project initialization or an agile framing, the ideal is to have our lot of US with a story-mapping realized because this practice really useful to obtain a simplified vision of the future backlog to achieve.

This graphical representation proposes only simple items in the form of a post’it where we have written the minimum to understand the proposed functionality. Here is an example of representation below:

priorized story mapping
priorized story mapping

I suggest you to read a more complete article on the story-mapping that I realized some time ago.

Article : Story mapping, a clear understanding of its creation

If you need to have an estimated roadmap, you should not hesitate to make an Extreme Quotation with these items.

This Extreme Quotation exercise can also allow the Product Owner to have a first view of the user-story workload. In a nutshell, we can estimate between 40 to 100 user-stories in just 40 minutes.

 

2 / My items become user-stories in my backlog

The Product Owner out of story-mapping, will tranform the items into user-story without ever going into detail.

It would be totally premature to complete the user-stories at 100% at this step because we know that functional requests will still be able to change, disappear or even add. In order to optimize the valuable time of the Product Owner, we will stop at the level of the summary of the user -story.

For example the item “Rate Product” will just become “As a Customer, I want to be able to rate the product to give my opinion to other customers”.

3 / We develop the user-story

When the Product Owner thinks to propose a user-story in the next sprint, he will develop his content during the previous sprint.

By following our workflow, the Product Owner will perform the description and the acceptance tests while the UX / UI will create the wireframe and design part.

This approach of waiting for the right moment is not logical at the first time but it is really efficiency.

4 / Proposal to developers

The Product Owner will present the user-stories to the developers to submit them to validation or even their estimate.

In a few cases, the Product Owner will notice that the technical work is bigger than in his imagination but that is not a real issue. He will put it in stand-by for a next sprint.

=> However, if the work of Extreme Quotation was done during the first phase of maturation, this problem will be rarely encountered. It is also a way of optimizing productive work (ie reducing the loss of time).

In some cases, the developers will ask to split the user-story or to improve it. No problem, the Product Owner will do this work after this Product Backlog Refinement.

A / The feedback in review or demo

When key users or stakeholders make their feedback, the Product Owner will add them in the story-mapping and backlog in the simple form of the summary.

He will only process the complete content of the user-story at the desired time as he does with the initial requests.

Conclusion write your user-stories

The evolution of the backlog must also be iterative and incremental. We can even talk about PDCA because the Product Owner must note any feedback from developers during the Product Backlog Refinement to improve the content of future user-stories.

So, there is no secret for you; You know write you US in optimal form. Do not hesitate to share your tips with other readers of this blog.

 

(Visited 1,920 times, 3 visits today)
About Judicaël Paquet 368 Articles
Judicaël Paquet (agile coach and senior devops) My Engagements in France and Switzerland: - Crafting Agile Transformation Strategies - Tailored Agile Training Programs - Raising Awareness and Coaching for Managers - Assessing Agile Maturity and Situational Analysis - Agile Coaching for Teams, Organizations, Product Owners, Scrum Masters, and Agile Coaches Areas of Expertise: Scrum, Kanban, Management 3.0, Scalability, Lean Startup, Agile Methodology.

4 Trackbacks / Pingbacks

  1. Comment écrire ses US avec une approche incrémentale et itérative - Blog Myagile Partner
  2. What's a backlog? - Blog Myagile Partner
  3. Backlog - english definition - My agile Partner Scrum
  4. Product Backlog - definition - My agile Partner Scrum

Leave a Reply

Your email address will not be published.


*