Hey Agile Fans! Welcome back to another exciting Agile blog. We all enjoy a good story,
don’t we? Some like mystery, drama, romance, and such! In our last blog we learnt how
agile principle/ practices can be applied to non- software teams as it allows us to
harness change while giving customers the advantage. In this issue, you will learn about Agile User Stories. These are of course exciting stories told from the perspective of those that require a solution to a problem! I’m sure you are already building your agile-ability so buckle up your seatbelts, this will be another great blog just for you so let’s dive right in!
A user story is a specific, predefined and simplistic way of documenting requirements and desired end-user functionality. It is one of the main tool used within the agile community. We have learnt that being agile requires internalizing the Agile mind-set, values and principles, and then mastering how to apply the right practices and tailor them to work situations as they arise over time. While a user story can be perceived as the common language that builds an understanding between user and the development team; often times there is a breakdown, commonly occurring within the requirements gathering process. This poses many challenges in our organizations, hence teams experience many challenges with user stories. Let’s take a closer look at some possible reasons for this:
SOME PROBLEMS WITH CUSTOMER REQUIREMENTS
- Requirements tend to change, sometimes often. Different surveys show that more than 35% of all requirements change during a typical project / product development.
- Frequently, the client doesn’t know what he/she “exactly” wants. Even if a client knows what is needed, he/she may struggle to articulate or define such. In other cases, some clients also do not know much about technology, and hence think they have to articulate in technology “speak”.
- Even if the client defines the requirements very well, we may have completely misunderstood the client and implement something completely wrong.
Fortunately, a user story is an agile requirement technique which can help with this challenge. It is simply something a user wants. It is a description of a feature told from the perspective of the person who desires the new capability. E.g. As a user I want to have the option to pay via a Master Card credit card so I can complete my online transaction.
A USER STORY IS SIMPLY SOMETHING A USER WANTS
Three C’s of a user story:
- Card: Just enough text to identify the story
- Conversation: details communicated between Product Owner (PO) and Development Team
- Confirmation: PO confirms whether or not the story implemented correctly.
Let’s take a look at some challenges with User stories and how we can overcome them.
- Overwhelming Details – Ever seen stories too big and vague for the team to understand
and implement? Getting the details right seems to be a battle the product owner can only
lose. What would be beneficial is to start with big stories called epics particularly for all new
features. Epics allow you to capture an idea without committing to the details. Then break
an epic into more detailed user stories. The new user stories make up the epic, and they
provide more information about the product’s functionality. Bottom line is user stories have to be ready i.e. before the team can start working on a user story it should meet the Definition of Ready (DoR) criteria.
CAPTURE IDEAS WITH EPICS,THEN BREAK THEM INTO USER STORIES WITH MORE DETAILS
The User Stories DoR is as follows:
Criteria (INVEST):- Independent: has no overlap with other stories and is not a compound user story addressing multiple separate requirements
- Negotiable: allows latitude for conversation about further details on requirement which results in a collaborative effort between the product owner and the team.
- Valuable: Delivers added business to the product. Remember the “so that ” clause of the user story
- Estimable: Sufficient details made available for developers to estimate the work for proper prioritization
- Small: sized appropriately that it can be implemented within a single sprint.
- Testable: must have clear acceptance criteria agreed with the stakeholders.
- User Story is unclear to the development team or PO – typically, there’s no clear acceptance criteria or none at all, and the development team is struggling to understand the scope of the story, how this story fits with the overall goal of the product, or how to specify the tests. Developers need to understand certain things about user story to implement it well. Unclear user story causes lots of waste during a sprint, and stories are traveling from sprint to sprint. It is important that all user stories are clear have well defined acceptance criteria.
- Acceptance Criteria Dilemma – Acceptance criteria are often times misunderstood. Sometimes there are detailed user stories without any acceptance criteria that restate the story description, criteria that hide new stories, or even contain entire workflows. The last two mistakes are exemplified by the following story (the narrative is on the card on the left, the “acceptance criteria” on the right):
What is the idea behind an acceptance criteria? It is simple, you should describe the conditions that have to be fulfilled so that the story is done, that it can be exposed to the users and the other stakeholders. As a rule of thumb three to five criteria per story is ideal. Ready stories, however, must provide meaningful criteria.
- Wrong purpose – User Stories describe end-user requirements, they aren’t designed to capture technical requirements. A typical example of wrong use of user story for technical requirements is “As a developer I want …” Unless a developer is the end-user of the product, this is the incorrect way of defining a requirement. However, to capture technical requirements they should be listed as tasks on the product backlog; and linked to user stories/epics if necessary.
- User Incognito – A user story tells a story about a user interacting with the product. However some stories discard the beneficiary altogether, or they talk about a hidden user as in “As the user, I want to …” But if it’s not clear who the user is, why should the story be developed? How can we be confident that the story will benefit someone? The solution is to make sure that all your stories have a clear user or customer. What is helpful is to use personas instead of user roles. This connects each story to the right persona, and it allows one to understand it, and to which extent the story addresses the persona’s need or goal. To achieve this, we can use the following template: As <persona>, I want <Something> so that <benefit>.
- Faulty Product Owner Selection – The PO is responsible for writing user stories along with the help of the development team. The PO is the voice of the customer and provides the voice of truth for the scrum team. When a client assigns a PO solely based on his/her availability, we are likely to encounter additional problems:
- A deficit in product knowledge and expertise causing delays in communication and progress.
- Decision making hampered as PO is not empowered and or privileged.
- A breakdown in communication and collaboration among stakeholders commonly resulting in erroneous requirements.
In order to help our organizations overcome challenges with user stories, it is imperative that we communicate efficiently, effectively and adhere to the best practices for creating user stories. Accurate selection of a PO is vital, as it strengthens the gathering of requirements and the project’s overall success. These are strong factors needed to build the foundation for good user stories. What are some ways you can help your team overcome challenges with user stories?
We’ll catch you in the next issue. Look out for many more blogs to build your agile-ability (get it)
