Techniques for gathering user stories
Product Hierarchy of Agile Software Development:
The Agile Product software hierarchy is developed top down. The starting point is to map out every one of target customer’s missions and define all. The Product Hierarchy has been broadly divided into various labels based on the position they sit in the hierarchy.
There are various names like Idea (Theme), Initiative (Vision), Feature, Epic, User Story and these are often interchangeable. The lowest level artifact is always: a User Story. Stories need to be developed as a part of the Release Planning. Stakeholders and P.O. agree on what features/epics will be developed in a release cycle. If it isn’t in the release cycle, the team will only provide high level estimates.
Every initiative starts with a product vision documented in black and white. The vision describes why the project is being undertaken and what the desired end state is.
The vision addresses 5 questions:
- Who will buy the product? (Target customer)
- Which customer needs will be address?
- What are the critical attributes for success?
- How does it compare against existing products? What are the unique selling points?
- What is the target timeframe and budget?
A good Product Vision aids in creation and organization of product backlog and determine “minimum viable product” which is critical to achieving the business benefit.
PO plays a vital role in dealing with the Product Hierarchy. The PO acts as a funnel between the business stakeholders and development team to collect the requirements, prioritize the requirements and convert them into work items (aka User Stories).
Few Techniques which are Product Owner may use are for gathering User stories are :
- Market Research
It is a very important strategic step in execution to gather the information about the target customer requirements. It is also a key factor to remain competitive over competitors. It also provides important data points to identify and analyze the market size, market needs and various customer demographics..
It may also include opinion research about individuals in an organization for various interpretations using statistical and analytical tools and techniques available for efficient decision making.
- Surveying Users
Kano Analysis
Kano Analysis is one of the surveying technique under which features of a product are categorized into 3 sets
- Exciters/Delighters à Features a user don’t know she wants, until she sees it.
- Linear à The more of it, the better
- Mandatory/Baseline à Must be present in order for the users to be satisfied.
To assess whether a feature is baseline, linear, or exciting we can:
- Survey a small set of users (20-30). We ask two questions
- A functional question: How do you feel if a feature is present?
- Example: If you receive your monthly bill through email, how do you feel?
- And a dysfunctional question: How do you feel if that feature is absent?
- Example: If you receive your monthly bill through snail mail, how do you feel?
- We will choose and answer pair based on the responses and aggregate the results.
In the Product roadmap, we will include the entire baseline set of features, some amount of linear features and Leave room for at least few exciters.
- Expert Opinions:
- Theme screening
Identify 5-9 (approximately) selection criteria for what set of features are important in the next release an follow the following steps,
- Select a baseline feature likely to be included in the next release understood by most team members
- Assess each candidate feature relative to the baseline theme
- The features with the highest scores in the decreasing order are picked up for the release to work on.
- Theme scoring
- It is very much like theme screening but selection criteria are weighted
- Need to select a baseline reference feature for each criterion. It avoids compression of a category.
- Each feature is assessed against the baseline for each selection criteria with the ratings given below in the table
| Much worse than reference | 1 |
| Worse than reference | 2 |
| Same as reference | 3 |
| Better than reference | 4 |
| Much better than reference` | 5 |
- The numbers are aggregated to rank them in order. The first few highest ranked features are picked up for the release.
- Mathematical calculations
Relative Weighting
- Assess the impact of having a Feature from 1 to 9
- Assess impact of NOT having it from 1-9
- It then calculates the value of each story or theme relative to the entire product backlog. This gives the relative value of that Feature.
- We need to estimate the cost of each Feature. Calculate the cost of features relative to the other features in the entire product backlog.
- This gives the relative cost of that story or theme
- Priority is given by (Relative Value ÷ Relative Cost)
- Prioritization Techniques:
MoSCoW Method:
A MoSCoW is an acronym of MUST Have, Should have, Could have and Want have.
Must Have
- Business goal/benefit is not accomplished without the story
- Product cannot go to production without it.
Should Have
- The purpose would be accomplished but an undesirable compromise or work around would be needed
Could Have
- The purpose would be accomplished but a desired improvement would be lost
Want but Won’t Have
- Often called “gold plating.” A story which extends functionality beyond what is necessary for the purpose or for which there is unclear benefit
- The Must Have Features are features need to be present for the software to be able to accomplish the purpose of a release
- This defines what the minimum level of success for the team in a particular release. If any must have story is not delivered, the release is a failure
- If all stories are “must have” in a feature / epic, the release is in danger
- Organize into piles by MoSCoW rank. Move the “Won’t Haves” out
- Force rank each MoSCoW category based on highest level of business to lowest, if known