Effective Project Scope Management with Agile User Stories
Project Scoping is the most essential part of project planning. Without it, the company will have no idea how much time, money, and labor need to be involved.
To execute the project successfully, we first need to understand what is needed to achieve the project's goal and plan how to get and then organize all required resources. It is extremely important to scale the work right at the beginning and ensure the whole team stays on track the entire time.
The simplest way to do it is to define the Project Scope.
In inCode, the project scope consists of decomposed user stories. There are two steps that we undertake when working on the Project Scope:
- User Stories & Epic
- User Story Decomposition
Step 1. User Stories & Epics
A user story is a description and explanation of a software feature written from an end-user perspective in a non-tech language. User stories help explain how each software feature will create value for end-users. This approach is extremely important since it puts the end-user in the first place, and helps communicate with the client in the same language. It fosters collaboration and creativity and gives you a guarantee the product will meet or even exceed the client’s expectations.
In addition to this, it is a great preparatory tool for project scoping and scaling.
How to write user stories?
Each user story needs to consist of:
- User statement
- Edge Cases
- Acceptance criteria
- Design links (if acceptable)
A user statement consists of 3 parts and describes the action from the user’s perspective. Here is a basic structure of the user statement with an example below:
As a ________________ user, I should be able to ____________, so that I can ____________
As a user, I should be able to see the contact form, so that I can easily get in touch with the company and discuss my need
Assumptions are different scenarios upon which the user will successfully complete the action. For example, if we are describing interaction with the contact form as a user story there can be the following assumptions:
- There should be a Contact Us button on every page
- The contact us button should have a fixed position
- A user should be able to leave a message via Telegram, WhatsApp, Facebook Messenger, and Email
Edge Cases are pitfalls that might appear during the action that will worsen the user's experience. It is important to highlight those so that the team can take them into account during the development process. For example, in the case of a user registration story, there can be the following edge case If a user registered via email, he should not be able to register via Google.
Acceptance criteria include what needs to be checked by the Tester to make sure the user can successfully complete the action with all assumptions considered and taken into account. The acceptance criteria can be The user is able to easily get in touch with the company or The user is able to log in into the personal profile.
The design links are not an essential part of the user story and are not included by most companies. However, including links to great design practices might save a lot of time in the future. Researching successful examples from the industry will also assist you with compiling a list of edge cases.
What are User Epics
After stories are written we need to group them into a small cluster to be able to set priorities and scale the project. User Epics are a group of stories under the same topic. For example, user stories - Registration, Login, Restore Password will be grouped under the epic Authentication.
A list of high-level epics and stories is what we use as Project Scope to present to our client.
It’s important to note that this is only the high-level decomposition of the project where the goal is to make sure you are your client are on the same page. Later on, you with your team can make adjustments based on the restrictions and opportunities you discover during the development process.
We believe that this is the most effective way to break down the project into small parts as non-programming, casual language fosters collaboration between you and the client and puts the user or the client at the center of the whole process.
Step 2. Story Decomposition
When you agree on the final list of user stories and achieve a fair understanding of what the client’s expectations are, we can start decomposing the stories into tasks for our team.
We decide which stories should be covered first, and which ones can be built on later.
Project managers break down each story into Development, and Design tasks. Depending on the teams' structure, designers and developers can internally break down tasks into smaller sub-tasks: Back-end tasks, Front-end tasks, Prototyping, Visual Design, etc.