From Vision to Epics to Stories to Tasks – Agile Requirements Management Simplified
Daniela Field / July 19, 2017
One of the challenges with agile development is capturing requirements. In an ideal world, agile requirements management is simple because the customer already knows what they want, the developer knows how to build it, and nothing will change along the way. But how many projects have you been involved with that progressed in this ideal way? From my experience, zero.
The reality is that the customer will discover what they want and the developers will discover how to build it. In addition, a lot of things will change along the way. Change is the only certain thing in life. We can choose to fight it, or we can manage and harness it.
Getting Started with Agile Requirements Management
To get started with managing Agile requirements, I’d recommend watching Sr. UX Designer Willem Gorisse’s Successfully Integrating UX in Mendix Projects webinar. From this webinar, you will learn to start by using the product vision template and mapping out the user personas that will be using the solution.
Why should you start with the product vision? Because the product vision highlights the reason behind the product being built. As you are developing the solution, the vision should be the driving force that keeps everyone focused, especially when “scope creep” starts to happen. The Product Owner should drive the vision and manage the stakeholders’ requirements. Think of the vision as the reason WHY you are building the solution. The epics, stories, and tasks will be WHAT you are building.
Epics vs. Stories vs. Tasks
Once the vision is clear, you can start by creating epics and breaking down the requirements. Epics are whole features and functionalities that can span multiple sprints. They are broken down into stories, and stories can be further broken down into tasks. An epic will have multiple stories, and each story can have multiple tasks. While epics can span multiple sprints, the stories should be done within the current sprint.
Stories should be prioritized and created based on feedback from stakeholders. The Product Owner should prioritize as needed and guide the team. When creating stories, this template should always be used: As a <user role>, I want to <what you want> so that I can <business value added>.
If there is no business value to a story, then why are you building it? Asking for the business value is also a good way to manage scope creep and identify when stakeholders are requesting a lot of items without clearly defining why. Each story can have multiple tasks that break the story down further.
Best Practices for Managing Agile Requirements
The great thing about Mendix is that Agile management is incorporated all in one place. You can create sprints, manage stories and tasks, and add various labels to capture all the requirements needed. This is all found within your app’s Stories section.
There is also a agile sprint planning section where you can manage the entire release plan.
The requirements are integrated with a development environment under the Stories view. Notice that only the current sprint will show up in the Stories view. The reason for this is to keep the developers engaged and working in the current sprint.
As a developer is working on a story, they can mark it as Running when they are working on it and Done when they are finished. Once they are finished with the story, they should attach the story to each code commit they do.
If the team sees any impediments or if the Scrum Master notices anything that will be a future roadblock, they should raise such issues as soon as possible. There is no time to sweep things under the rug in Agile development. While you cannot account for all issues, it is important to know that every change made to the app during an iteration has a cost.
The more complex a project, the longer it will take and the more issues will arise. When dealing with complex requirements, it is important for the development team (along with the Scrum Master and Product Owner) to plan and design the solution as best as possible. That means breaking up complex requirement into smaller stories and iterating over time. The feedback from stakeholders is one of the most important links between business and IT, and it should be harnessed.