Q 421. In Agile product development, a user story is a simple, clear and short description of a customer valued functionality. A user story is expected to meet INVEST guidelines. Explain INVEST and highlight the one guideline from the six that you consider as most challenging to follow.

 

Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday.

• All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/
• Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening 5 PM as per Indian Standard Time. Questions launched on Tuesdays are open till Friday and questions launched on Friday are open till Tuesday. 
• When you respond to this question, your answer will not be visible till it is reviewed. Only non-plagiarised (plagiarism below 5-10%) responses will be approved. If you have doubts about plagiarism, please check your answer with a plagiarism checker tool like https://smallseotools.com/plagiarism-checker/ before submitting. 
• The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term

Invest is widely accepted checklist/ set of criteria to access the completeness and quality of a User Story. If the any of the user stories fail to meet any one of these criterion, the team is directed to rework or rewrite to ensure alignment to guideline. The criterion was coined by Bill Wake and stands as an acronym for simple rule set that is advised to be used in creating a well frame user story.

 

• Independent defines that Stories should not be dependent on other stories. The user should try to make sure that stories or the specific feature are not interdependent as it leads to prioritization and planning problems. Independent and logical order of developing things are distinctive. For example, for credit card payment related user story and we want to support payment by ICICI, Mastercard and Visa and  if we had a story for MasterCard and another for Visa, then the estimates will depend the one prioritized and implementing the other story will just be a replication . hence there needs to be clarity and have one story stating primary payment option using VISA and the other can then change to “provide a secondary payment option using ICICI.
• Negotiable emphasize to capture the essence of the requirement to encourage ongoing conversation and scope negotiation between the customer and the developers and should not represent a contract on how to solve it.
• Valuable require the stories to be clear in illustrating the value delivered to the customer ie If a customer cannot think of a value statement, then we should de-prioritize the story or will lead to effort wastage later The value statement represents why the feature is being built. Presenting the team with the Why implies the value delivered and not just the What  which defined the feature and can trigger different ideas of alternate features easier and faster to develop and still meet thesame goal and deliver the same business value. Since story is delivering a piece of functionality, the customer can figure out the ROI of the functionality i.e. its costs and then decide if its is needed
• Estimatable requires to provide just enough information so that the stories can be estimated. It is not important to know the exact way that a particular problem will be solved but must only be understood enough to provide a high-level estimate.
• Small – Stories should strive to be granular enough in scope that they may be completed in as little time as possible, from a few weeks to a few days.
• Testable – requires testability of the user story to help determine completeness The criterion required to have a acceptance criteria which has to be objective and to avoid using criteria like easy to use, fast or bug free but to write criteria that can be measured and tested (ideally automated). For example, test that payment verification responds in 1 second or less at least 95% of the time.

 

Many times getting the crux of what the user requires in itself is challenging and required multiple levels of discussions to frame the product vision and then driving the features and the value these deliver to enable the product vision. For a stakeholder all the user stories will be critical and hence asking them to substantiate the value delivered from each of the user story and prioritizing these may be challenging. They perceive all the user stories to be critical to product delivery.

 

However the Negotiable criterion also many times leads to discussions between the development team and the product owner at later point of time as it becomes challenging to capture the essence of the user story.

INVEST is an acronym, which is the widely used acceptance criteria or checklist to assess the quality of a user story. If a user story does not meet the criteria, the team can either think of rewording or even rewriting the user stories. INVEST states that a good user story should meet the following criteria

I - Each user story should be Independent of each other.

N - It is should be Negotiable and not having a specified contract.

V - The user story have have a Valuable outcome.

E - It should be Estimable.

S - Should be Small.

T - Should be testable to say that it is "done".

I feel that it is challenging to get independent user stories and most difficult to address. Dependencies lead to prioritization challenges and planning issues. Also dependencies can make the estimation much harder to do. One solution is to combine all dependent stories into one user story. But combining can also lead to bigger user story. Hence I feel it is challenging to make all user stories independent.

User Stories if well captured is a treat for the readers.

 

INVEST acronym is a  set of 6 guidelines coined by Bill Wake, a Senior consultant with Industrial Logic.

The term was first used in an article by him and subsequently found its way to his book "Extreme Programming Explored" .

 

INVEST stands for:

 

* Independent: Stories should not overlap else could pose problems for prioritization

* Negotiable: Should focus on the user requirement rather than diving into how it was met.

* Valuable: Must depict value to the customer

* Estimable: Stories giving  information enough to arrive at rough estimate is acceptable

* Small: The scope of the stories should be crisp so as to complete it in a few days

* Testable: Story that has no user acceptance criteria cannot be tested and hence merits             defining the same.

 

The INVEST guidelines have some roots from SMART(Specific,Measurable,Achievable,Realistic,Timebound) framework and also gives clear shades of using MECE(Mutually Exclusive and Collectively Exhaustive)framework.

The acronym INVEST is a guideline to come up with a well-written user story. A good user story should have:

• Independent (story should be independent of all others)
• Negotiable (story is not a contract, rather it is a trigger for conversation or brainstorming)
• Valuable / Vertical (story must show value or prioritization otherwise it should not be done)
• Estimable (to a good approximation)
• Small (so as it will fit in multiple iterations)
• Testable (story must be validated before we say it's done)

Out of these 6 guidelines, the most challenging part to follow is Independent. Simply because people always tend to relate or connect details of their story to one another, making it challenging to break apart in order for the story/stories to be worked on in any order. This somehow coincide with Valuable as we loose track what is really the priority of the user in their story.

INVEST criteria in Agile plays an important role to design and draft a good user story. It shows you the procedure to prepare the user story in such a way which shows the way to specify the requirement following the Agile value and principles.

An effective user story should follow the below criteria:

1.     Independent

2.     Negotiable

3.     Valuable

4.     Estimable

5.     Small

6.     Testable

 

·       Independent: The story should not dependent on other story because it might cause the delay in implementation if the other story is taking time.

·        Negotiable: The story can be more effective when both the product owner and development teams builds a story with shared understanding and connects everyone’s expertise. The product owner and the development team always open to modify the requirement to get an effective result.

·        Valuable: The user story should state the value to be added and how it will fulfill the user’s requirement along with the risk mitigation plan and cost is to be involved.

·        Estimable: The story should give enough details to the development team to estimate the size of the story. You should have an idea about size of the story so that you can plan a recapitulation that will deliver the working software. Size is more important to get help in prioritization.

·        Small: Agile works in short iterations so you can get fast feedback from your users. Small stories always required small iteration if working software is to be delivered for each iteration.

·        Testable: The software should be eligible for testing before delivering that. If you cannot test any solution, you will not be able to gauge the effectiveness of the solution. So, the software should be testable.

 

Note: As per my understanding the stage Negotiable is most challenging as it needs a strong co-ordination between the product owner and the development team.

 

Thank You!

 

User Story. The term user story was first coined by Alistair Cockburn in 1998 and adapted in the Agile framework by Mike Cohn in 2004. In a Project, a user story is a way of describing the features of the system, in an informal natural language that is understood by the layman. These are generally written from the angle of the end-user of the system.  It may be written by different end-users of the system so that the entire user’s requirements are captured for all functions. The User Story has various templates such as the role, the capability, and the benefit or the 5Ws: who, when, what, why, where. These templates facilitate the making sense of a problem without the problem of undue structuring.

INVEST. The Acronym INVEST was first used by Bill Wake to define the characteristics of a good Product Backlog Item that is used in the User Story.

Independent. The User Story should be independent. By independence, we mean that the User Stories could be taken up for work in any sequence. By doing this each User Story could be prioritized independently of other User Stories. If the User Stories are dependent and a more valuable story follows an invaluable story, it would not be possible to prioritize the more valuable story above the invaluable story. User Stories may be combined to make them independent.

Negotiable. A User Story is used to begin a conversation and is not set in stone. The User Story gives the main essence of what is required. The final requirements are them worked out between the customer and the designer through negotiation and collaboration. The aim of the User Story is a starting point to understand the needs of the customer.

Valuable. If the User Story does not have sufficient value, it is not prioritized and not done. At times a User Story may not create value for the end-user, but would be some non-functional requirement that is necessary thus creating some value to the business process. The value/benefit clause in the User Story Template would indicate the value that the User Story is desiring to deliver.

Estimable. In order to prioritize the User Story, it is important to be able to accurately estimate its size in terms of resource requirements. At times User Stories that take a lot of time are given lower priority. In such cases, the User Story may be split into small parts to be able to estimate them more accurately and increase the priority. In case you are unable to estimate the User Story, it may be necessary to redefine the User Story. Stories that cannot be estimated, cannot be used as they cannot be made part of any iteration.

Small. User stories should generally take between a few person-days to a few person-weeks. In general, a single-story should not consume more than 50% of the time. It should be small enough to be done in a sprint.

Testable. In order to do a story, it has to be testable. To do this the story should have laid down and acceptance criteria for testing.

Challenging Guideline to follow. Even though each of the guidelines may pose its own challenges, the guidelines of an “Independent” and “Small” User Story could be contrary to each other. Smaller User Stories may have to be merged together to create an Independent User Story thus a balance between the two would be a challenge.

Conclusion. Firstly, successful implementation of the Agile framework requires a change in the organizational culture. Secondly, the more time spent on INVEST User Stories, the better will be your understanding of the user’s requirements which inevitably leads to cohesion amongst team members, and a shorter time to complete the project.

References

https://en.wikipedia.org/wiki/User_story

https://en.wikipedia.org/wiki/INVEST_(mnemonic)

https://agileforall.com/new-to-agile-invest-in-good-user-stories/

https://capgemini.github.io/agile/invest-in-user-stories/

In Agile User Story, if we want to express the challenges/problems/issues, we use either one or more of the 6 different qualities which is coined as INVEST. Product owner can use either of the INVEST qualities to make a good user story.

INVEST is an acronym for:

·       Independent

·       Negotiable

·       Valuable

·       Estimable

·       Small

·       Testable

 

In my opinion Small is one of the qualities which is most challenging to follow. There are several challenges we see. Some of them are below:

 

·       Fail to plan for small iteration – We are so used to waterfall model that we add more deliverables in the Sprint and fail to plan for smaller sprints

·       Misunderstanding the Sprint as Project and not a product – Most of the cases, it is difficult to get the by in from the stakeholder as they see it from a project angle and not as a product.

·       Financial challenge - We will not be able to update the finance team for overall cost for the project. However, as the Sprint progresses, the financial is looked into. This becomes a problem to get sign off from the Finance.

·       Overcommitting – To deliver some specific product we sometime add more items into the sprint and therefore, keeping it small is very difficult.

 

Since we are evolving every day, I am sure we will embrace the change from Waterfall to Agile in coming days and therefore, we will overcome the challenge and will be able to break down the project into smaller product smoothly.

In Agile the acronym INVEST is a set of criteria or checklist use to gauge the quality of a user story. A good user story must be Independent- Negotiable- Valuable- Estimable- Small and Testable.

Independent- user stories should not overlap and be independent
Negotiable- user story is a mode to encourage conversation and not a contract
Valuable- product backlog item should be prioritized based on the business value and should be obvious
Estimable- should be able to estimate the size of the product backlog item.
Small- product backlog items should be planned for a few person days and max few person weeks.
Testable- to be considered “done” a product backlog item should be testable.

 

Strict adherence to the INVEST guideline reduces the risk by ensuring only the worth users' stories make it to the sprint. 

 

Independent is the most challenging of the six guidelines to follow, as we need to be cautious as much as possible not to make the stories interdepended which might impact the problem prioritization and planning.

 

The INVEST is an acronym which stands as a criteria to evaluate the quality of a user story in Agile product development.

• Independent :- Characteristic which helps to prioritize the PBIs or club it with one another.
• Negotiable :- Ability to negotiate on the feature and functionality.
• Valuable :- Availability of specific user value which are readily recognizable.
• Estimable :- Ability to size the PBI so that the same could be planned effectively.
• Small :-Keeping the PBI size to manageably small, ensuring the thumb rule not to exceed 50% of an iteration in a single PBI.
• Testable :- Ability to test and verify the completion of a user story

Out of the six guidelines , I believe the “Estimable” is the most challenging guideline to follow. The story point are very much relative in nature and are mostly without connection to any measurement unit. The primary challenging part is to decipher the volume of the work, complexities involved, Known and unknown elements in story points. The next stage would involve in predicting the team’s velocity, capacity and baseline for estimation.

The agile team uses story point or estimation poker to estimate the value of work. The story point uses volume, complexity , knowledge and uncertainty as the combination of qualities represented as singular number. The estimation poker mostly uses an expert opinion combined with analogy and disaggregation.

User stories are the building blocks of an agile framework. The purpose of a user story is to clearly articulate how a developed work will deliver value to the customer. Hence, it is important that the team (Product Manager) creates meaningful user stories for the successful project delivery. INVEST is an acronym that is followed when creating meaningful User stories. It stands for:

 

Independent – User stories should be self-contained units and independent of each other so that each of them can be developed and delivered separately.

Negotiable – User Stories should not be close ended i.e. there should be room for negotiations (for improvement) between the customers and the development team.

Valuable – Each User Stories should result in adding value to the customer and hence should be properly aligned to customer’s business goals.

Estimable – User Stories should be created in such a way that the development team can easily understand complexities of work and be able to estimate the efforts required.

Small – User Stories should be appropriately sized to be completed in 1 Sprint (2 weeks).

Testable – User Stories should be testable to help determine completeness i.e. fulfil customer’s requirements.

 

One of the challenging steps in developing the User Story is to make it negotiable. Even with a technical heavy Agile team (which is most often the case), converting all the customer expectations and requirements into technical solution/ features is not entirely possible. There is always be a gap between the customer expectations & technical feasibility. Another challenge area is in user story testability. Most of the test scenarios created are based on the product development team and not based on the customer requirement. the test scenarios just considers whether the User story has been successfully developed but not whether the value has been created from it. 

 

In Agile methodology, iterative development approach is followed and the planning, development, prototyping and other software development phases may appear multiple times. This is flexible and the changes are detected in early stages to ensure the final launch product is 100% acceptable.

The Product Owner of any Software Development Project will produce user stories (requirements & functionalities in the form of user stories) before the Development team. The User Stories are developed in INVEST format. This criterion was suggested by Bill Wake.

Independent | Negotiable | Valuable | Estimable |Small |Testable

Independent	Negotiable	Valuable	Estimable	Small	Testable
The user story should be always independent and have less coupling with other stories to minimize the complexity of estimating, prioritizing, and planning	To avoid any kind of conflicts the User Stories should be always open for discussions and are expected to be negotiable. This is to ensure the development of the functionality is acceptable by the customer and "not to waste" the Human Innovation efforts contributed by the developers	The User stories should be value add to the customer and Valuable to the User.	The Estimates help in designing and developing of the product and hence the user story should be able to provide estimates. This estimate will further help in formation of size of the stories	Deliverables are achieved in a sprint when the user stories are smaller. This also helps in developing a component/feature faster	The developed output based on the user stories should be available in Acceptance/Rejection Criteria. In other words, user stories should be feasible for testing

 

In my opinion the difficulty arises at “Negotiable”, and this is due to the non-alignment on the value features aspired by the customer/ user with the entire team (Product owner, Scrum Master & Developers Team).

The discussion should be productive, people should be open minded, experimental to develop a viable product/feature and the alterations to the user stories should be welcomed. During Negotiations Product Owner plays an important role in advancing further development while adding vibrancy and collaboration.

INVEST is acronym can help you to identify features of a user story. Its stands for

“I” Independent –a user story explain concepts of a system's capabilities & ensure that there is no overlapping (means independent) of concepts so that we able to schedule & implement in any order. Common types of dependency- Overlap, order & containment.

“N” Negotiable - a user story gives details about the importance of collaboration, evolutionary of design and feedback, which is provided by the customer or design team. Negotiable is concept about team work, ideas sharing & share the results.  

“V” Valuable - a user story is need to be valuable in customer point of view what goal is achieve. Our thinking for a user story is not valuable whereas customer conscious is important to finalize the user story is valuable or not.

“E” Estimable - a user story is estimate not exact but enough to track the customer position, cost and schedule, it is also partly a function of being negotiated.  If user story is not understand it is hard to estimate. Estimate will vary as per the team experience but it will make a mostly correct estimate.

“S” Small - a user story usually good if it is small. Small stories is more accurate to estimate customer position and schedule, having 3 levels of thinking –high (suggest- shape & extent, medium (suggest- role, action & context) and low (suggest- Only details).

“T” Testable - a user story is testable before the implementation gives the idea whether the goal is achieving or not. A testable storyline is one for which we can agree on the predicted system behavior and/or outcomes given any inputs.

 

“E” Estimable is most challenging to follow.

The functionality customer requires is described as simple, clear and short. This is user story. A user story has to meet INVEST guidelines. INVEST is the short form of the keyword that would help us in writing user stories

Independent, Negotiable, Valuable, Estimatable, Small, and Testable

Independent : Features of user stories selected should preferably be independent from each other. This will avoid prioritization issues later

Negotiable : User story should be simple, clear and short. It shouldn’t be a detailed description

Valuable : A user story which adds no value should be deprioritized or even eliminated

Estimatable : Story should be written such that the people referring it especially developers would understand and get and idea on the implementation of it. A story being estimable is important as it helps in prioritization. Eg a story with high value but estimated long time for development may not be high on priority.

Testable : Any story should have an acceptance criteria and should be testable. The criteria should be objective and have a definitive value that a subjective description

 

In my opinion, keeping the story independent everytime is the most challenging guideline. The stories could have a dependency on the other in real life.

Eg: If you are testing to check the steering functionality in a car. This cannot be a standalone functionality check as it is important to see if this has impact on other features say break, clutch, gear etc. Likewise the user stories may not be independent everytime, it could have a very strong relation to another story. So the most challenging seems to the Independent guideline.

INVEST is a guide for meaningful stories and helps to assess the quality of the user stories. If the user story fails to meet any one of these below criteria, the team must reword or rewrite it.

I – Independent – user stories should be independent from each other so each of them can be delivered separately
N – Negotiable – user stories should have scope of negotiation and further discussion
V – Valuable – User Stories should do value addition
E – Estimable – User Stories should be easy to understand and could be estimated basis tasks
S – Small – User Stories should not be too big, ideally it should not take more than 40 hours of work
T – Testable – User Stories should have acceptance criteria to test whether they fulfill the desired requirements or not

All responses are valid and very good.

The winner for this question is Chaitanya Shankar Nemani for well articulated and valid final comments on the most challenging aspect from the INVEST guidelines.