“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, and 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 stories 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 to 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 about why’s for every step from, why teams should include the feature up to 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 a 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 Product 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 a 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 log in. 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 log in 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. combine the basic sentences into complicated ones. 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 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 you 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 organizations 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 and move from concept to cash in the shortest sustainable lead time by adopting the human-centric approach to business agility. Embracing change is in our DNA. Things that keep us apart are Quicker and Seamless execution with an End-to-end gamut of services. Our Global presence and Stellar Track Record give us an edge over our competitors.
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.
Comments