top of page

User Story Mistakes

“Smart people learn from their mistakes but the real sharp ones learn from the mistakes of others.”



So let’s be real smart ones today, and learn from the mistakes of others who have worked on the same, pointed out some mistakes made, which lead to failure. As we have seen in our previous article on ‘estimating user story’ and ‘how to split user story’ we know the vital importance it plays in agile enterprises. To catch up, here is a brief description of the benefits or importance of user stories in agile.

Provides highest value delivery

  • It fosters collaboration

  • Brings users closer to each other

  • Boosts transparency

  • Provides shared understanding

  • Reduces risks

  • Builds product incrementally

As stakeholders and most of the time product owners write the user story. The product owners while writing user story must keep the below mistakes in mind and avoid them.


1. Adding too Much Detail

Too many details in a story are hard to change as it puts lots of constraints on it. It restricts adding new ideas to a story while developing. Postponing some of the exact details and writing user stories in as little detail as possible will work as a solution during writing user stories while providing value. For example, when a story has too many details the developer to whom this story is assigned will consider that the questions related to this detailed feature have already been answered. Making him assume only the checkpoint to be ticked is remaining. This will close the conversation regarding business making all the extra development space closed.


2. Writing Technical Stories

In most cases, the team moves towards writing more of the technical designs and requirements, which lacks the business perspective in it. The technical story is easy to be understood for a developer or technical person but for stakeholders and product owners it’s hard to derive the business value from the story and know if it’s worth the risk of completing. The technical written user story can be easily converted with the business perspective by using a simple 5 whys? technique. In this technique, it's necessary to ask a question in why’s for every step from, why teams should include the feature up till why the customers will be willing to use that feature. Providing finally required user story with technical as well as business value details.


3. Writing the Incorrect ‘Why’?

Most people confuse business value with business requirements. For example, in ordering food many want to see how many orders they have placed previously. This can be considered more as a business requirement than the business value. Whereas, while ordering food, the customer wants to see previous orders so that they can order differently than previous making it more like a business value. So products owners make sure the 5 why’s they are writing are correctly implementing the business values and not the business requirements.


4. Using a ‘Not’ Word in a User Story

No amount of time will be sufficient to ensure compliance. ‘Not’ is a word that can be used in no-situation which can be vastly used. For example, If a user story consists of, I do not want to enter my password every time I login. Then there are many ways to complete this condition. If the story is written without the use of ‘not’ then the answer may be something like, I want the password automatically filled when I login which is more specific. This way of avoiding not words will provide the team with a specific and finable requirement.


5. Using Conjunction in a User Story

Conjunction words such as and, or, as well as, but, etc. which combines the basic sentences in complicated. These words generally complicate the user story. The use of these words in a user story proves that the user story can be further broken into parts.

Along with writing reading the user story can also sabotage the product development making it essential to read and write the user stories correctly achieving better benefits. Taking the time and experience in writing the user story correctly will surely benefit in the longer run. But along with learning from the other's previously made mistakes, it is also necessary to observe your way of writing the story and its implementation to learn from your own mistakes as said, “It's fine to celebrate success but it is more important to heed the lessons of failure.”


About Advance Agility

We, at Advance Agility, are the new-age Agile Coaching, Consulting and IT services company. We enable end-to-end Digital Transformation. Agile execution is integral to our being. We are doing SAFe implementation with small, medium and large organization across the globe. Our vision is to be the leading Agile execution player globally. To keep adding value at every process stage. We are on a mission to empower our clients, move from concept to cash in the shortest sustainable lead time by adopting human centric approach to business agility. Embracing the change is in our DNA. Things that keep us apart are Quicker and Seamless execution with End-to-end gamut of services. Our Global presence and Stellar Track Record give us an edge over our competitor.

Connect with us at advanceagility.com to learn about SAFe and SAFe Implementation. Write to us at contact@advanceagilty.com for any agile training or consulting needs. We are always looking for competent agile trainers as well. So if you are a good trainer or want to become one, do get in touch with us to that we can learn, grow and achieve together.

16 views

Comments


Fill out the form to reach our course advisor

image (36).png
bottom of page