A core tenet of modern development processes is agile development. This development methodology stresses using small, bite-sized user stories to define what a system does from a user perspective, not a technical one. A user cares if a product is fast, easy to use, and solves their problem. They do not care if it follows a 3-tier architecture, has Mongo DB, or if it is using Rails or Asp.net.
Storyboard That provides an ideal platform to create agile user stories and spark conversation in a format that is much less taxing than a wall of text.
In the context of user stories, an “epic” is simply a very broad story that will later be broken down into many specific user stories. Starting with an epic aligns everyone with a single, high-level vision. The epic story anchors a project from the top down, and if it doesn’t make sense to construct an epic, supporting work is also going to be a waste of effort.
In this story, it is very clear what the long term vision is and what success should look like. A good epic story should include:
Especially when designing software, it is important to have a good vision of what the users will be like. Not every user will match this vision precisely, and there may be multiple categories of user, but these discrete visions need articulation. Thinking about users first guards against over-engineering and over-complication, preventing a new product from having something for everyone and being useful to no one.
Once an epic has been established and users have been defined, smaller, more specific stories can be constructed about particular user experiences. The stories below break down the outlined above into two narratives: looking up an order and re-ordering a product.
These narratives do not contain technical information; the users do not care how the results are achieved, so long as it performs the desired tasks. Similarly, the UX is depicted generically, to avoid stifling innovation or forcing a path. In general, stories should be:
These stories should invite conversation and questions, such as:
It is perfectly reasonable to create many stories; in fact, it should be encouraged. Some of these stories will never be used, but it is important to see the path they set down. This collection of stories will flush out additional requirements and influence testing.
The stories should provoke and inform discussion about how the software will be tested and what business rules need to be explicitly defined. For example:
An agile user story is a simple, clear description of a software feature from a user's perspective. It focuses on what the user wants to achieve, not technical details, making development more user-centered.
To create effective user stories, start with a high-level epic, define your users, and break down tasks into small, achievable goals. Use clear language and focus on real user needs instead of technical solutions.
User stories are crucial in agile development because they help align developers, users, and stakeholders around shared goals, encourage frequent feedback, and make projects easier to manage and understand.
An epic is a broad, overarching story that sets the project's vision. A user story is a smaller, specific task or feature derived from the epic, focused on a single user need.
Storyboards visually illustrate user stories, making concepts easier to grasp for students. They spark conversation, clarify requirements, and encourage participation in agile planning activities.