Unlocking consulting project success with user stories
In consulting and software development, delivering projects that meet client needs and drive business success can be challenging. However, user stories offer a way to bridge the gap between functional delivery and transformative results. Agile methodology centres on delivering value to end-users. And one key tool in this approach is the user story, which helps explain how a feature benefits a particular group and what impact it has on KPIs.
Read on to learn more about:
- What a user story is
- How user stories work in implementation projects
- What’s included in a user story
- Preparing to write user stories
- Writing user stories
- Getting started with user stories in consulting projects
What a user story is
In Agile project management, a user story is the smallest unit of work, representing a clear goal from the user’s perspective. It answers three critical questions for teams:
- What are we building?
- Why are we building it?
- What value does it create?
By focusing on the user’s needs, a user story provides context, establishes acceptance criteria and fosters collaboration between the client and the development team. User stories can help businesses overcome project challenges and turn them into opportunities for innovation and success.
How user stories work in implementation projects
In Adobe implementation projects, the “customer” is often not an external end-user. Instead, they’re the client themselves or the systems that Adobe products are integrating with. Clients may view writing user stories as unnecessary. However, in complex projects — where multiple teams and moving parts are involved — user stories are essential. They offer:
- User-centric focus: Emphasising the needs of the user, whether it’s a human or a system.
- Context and purpose: Clarifying why a feature matters, which helps the implementation team make informed decisions.
- Clear acceptance criteria: Establishing objective measures of success, enabling the team to determine when the task has been adequately implemented and tested.
- Collaboration: Encouraging shared understanding between the client and the team.
- Traceability and transparency: Linking user needs to features to improve transparency and accountability.
Overall, user stories offer a structured and user-focused approach to documenting requirements and promoting collaboration, clarity and flexibility throughout the whole implementation timeline.
What’s included in a user story
User stories are made of a persona, a goal or action and a desired outcome. So, the result should look like this:
- “As a [persona], I want to [goal], so that [desired outcome].”
For example, “As an ecommerce manager, I want to create a new product, so that it can be sold online.”
When creating the goal, focus on a single, specific action. Avoid describing multiple actions within the same user story, as this can mislead the value of each action for the user.
Avoid describing how that action should be performed, as that’s a part of implementation. The user simply wants to perform an action and get value out of it. Keep the implementation details within the acceptance criteria part.
The desired outcome is crucial. It should define the value the action adds, which collectively determines the project’s success.
Preparing to write user stories
Project set-up
The preparation process for writing user stories depends on the project scale and its stage. When dealing with a big project such as an implementation there are several phases before creating user stories.
At the beginning of the project, review project documents to understand the scope, objectives and key users to prepare for a discovery workshop. Make note of key systems and users involved in processes, existing flows, gaps between the provided documentation and work breakdown structure and areas that need clarification from the client.
Discovery workshop
The next step is a discovery workshop. This step engages stakeholders to define user roles, priorities, risks and needs. During the workshop provide an environment for active participation and collaboration. Drive conversations with stakeholders and encourage them to share their insights, ask questions and provide feedback.
After completing the discovery workshop, outline the following:
- User roles: Define who will be a part of functional flows and who will use the features. Ultimately this will ensure that the user stories describe the requirements for relevant personas.
- Priorities: Establish which flows and platform features are of highest priority to stakeholders, so the team can focus efforts on what matters most.
- Risks: Explore various scenarios and perspectives to identify previously overlooked risks or challenges to address in the future.
- User needs: Document user preferences, behaviours and pain points. These items may contribute to the desired outcome part of your user stories.
High-level requirement document
The next phase before writing a user story is a high-level requirement document. It should follow the discovery workshop to make sure everyone is aligned on the project direction. This document should be based on the key objectives, functionalities and constraints of a platform without delving into technical details.
The requirement document should include:
- Project overview: This section outlines the purpose and goals of the project.
- Scope: This outlines the boundaries of the project, including what is included and what is not. This section will help with managing expectations from the very beginning.
- Objectives: This section should clearly define goals and objectives that the project aims to achieve. These objectives should be specific, measurable, achievable, relevant and time-bound (SMART).
- Functional requirements: This section includes high-level descriptions of the desired functionalities or features of the system or product without detailing how they will be implemented.
- Non-functional requirements: Here’s where quality attributes or constraints that the system must adhere to are explained, such as performance, security, reliability, usability and scalability.
- Assumptions and constraints: In this section, detail assumptions made during the requirements gathering process and constraints that may affect the project’s scope, timeline or resources. It is important to identify these upfront to manage expectations and risks effectively.
- Dependencies: External factors or dependencies that may affect the project’s timeline, resources or deliverables are explained in this section. Identifying dependencies early allows for proper planning and mitigation strategies.
The high-level requirements document ensures everyone is on the same page and helps establish a clear, mutual understanding between the client stakeholders and delivery team. This document defines the beginning of collaboration and communication, which is vital for keeping everyone aligned and carrying out the project plan efficiently.
Epics
When the high-level requirements document has been reviewed and approved, be ready to transform it into epics. Each epic represents a large, yet manageable piece of work, like a high-level objective within a functional area that contributes to the overall vision. The process involves breaking down goals and functionalities into chunks of work. Here are a few steps to follow:
- Identify themes: Determine the main themes or categories of functionality in the high-level requirements document. The themes should give a rough number of epics to consider.
- Define epics: Create an epic based on each of the identified themes. Each epic will group together a set of related user stories.
- Prioritise epics: Arrange the epics by priority. Analyse each epic’s business value, dependencies, risks and strategic importance based on the approved high-level requirements document. This gives a clear understanding of which user stories to start with and which functionalities are most valuable for the project and should be delivered first.
- Refine epics: Perform a regular refinement of the epics to ensure that they are well-defined, achievable and aligned with project goals. Work closely with client stakeholders to clarify any new requirements and identify dependencies.
Writing user stories
Once you have defined the epics, it’s time to transform them into user stories by breaking them down into smaller, more manageable work items that can be implemented and tested independently. Here is a step-by-step process:
- Work with user roles. You should already have user roles prepared after the discovery workshop. On a mapping board, put each role into a separate column and each epic into a swim lane.
- Map requirements. Map functional requirements to epics and user roles. Add a simple value definition or need to each requirement. In the end you’ll have everything you need for writing user stories — personas, goals and desired outcomes.
- Write user stories. Keep user stories granular and independent from each other. Remember, user stories are instruments that drive collaboration and communication. The implementation of each user story should deliver a specific value to the end user.
- Define acceptance criteria. Each user story is supposed to be implemented at some point in time. Acceptance criteria are conditions that must be met when the user story is implemented and should be defined for each user story. Like any objective, acceptance criteria should be specific, measurable, achievable, relevant and time-bound (SMART).
- Create prioritised backlogue. Like the exercise done for epics, prioritise the user stories based on their importance, business value and dependencies. Create a backlogue of user stories ordered by their priority.
- Get approval. User stories are a collaboration tool. Have a review session with the client, get their feedback and refine the user stories as needed. Make sure the user stories remain relevant, achievable and aligned with project objectives.
Get started with user stories in consulting projects
In implementation projects, success depends on a consulting team’s ability to deliver functionality that meets the client’s requirements and helps them do more for their business. User stories are vital for making this happen. They serve as documentation of user requirements and promote collaboration between teams. Recognising the significance of user stories enables teams to develop functionalities that solve user problems and drive business growth for the client.
Keep these guidelines in mind when writing user stories.
Don’t:
- Describe several goals in one user story
- Describe a solution in a user story
- Describe ambiguous goals
- Capture technical requirements in user stories
Do:
- Start with epics
- Choose the correct persona
- Keep user stories simple and brief
- Add acceptance criteria
- Collaborate
Learn how Adobe Professional Services helps guide you in using Adobe solutions to create industry-leading customer experiences.
Anton Boiko is a business solutions architect with over 10 years of experience in the technology field. Boiko has worked in several domains, including telecom, payments and ecommerce. Half of that time he spent in software development working as a product manager.
Prior to joining Adobe Professional Services, where he works on delivering projects for Adobe Commerce and Workfront, Boiko was part of a Magento 2 core team leading the development teams working on the platform.
