How to plan your first product demo using user story map?
Are you confident about the first demo for your clients?
Scrum and Agile teams use various tools and visualization methods while they plan for release, it’s for everyone to commit to their goals and timeline. For a team, collective commitment is a result of the correct planning, estimations, and velocity they work with. The teams know about their planning and achievements for each sprint and release.
During the planning Scrum teams use the tools that enable the entire team to set their individual goals or task and track them. The tools may not be part of scrum practices but are used by teams to plan and keep everyone on the same page. This practice is called GASP, Generally Accepted Scrum Practices.
Clear the goal, less ambiguous is your project.
Clear goals are essential for effective planning of development. Goals are precise and describe the intention of users. Goals define the user’s journey. By combining each goal you get the user’s map for your application. For example “As a user, I want to login” can be a goal, but there are different ways to log in that are not considered in the goal. The user stories that link to the goals address the concern of the same goal. Goals give an overall picture of the activity of the user in your application.
Missing a project goal means missing the user experience. So as you create the goals you envision your project from the user’s perspective.
Steps are specific to goals. Steps reveal the process followed by the user to reach their goals. If the goal is to log in, we can have 3 different ways to login, like register and sign-in, or using social media like Facebook or Google. Since the goals are precise, the steps perfectly carve to support their goals.
A goal can have multiple steps, it’s necessary to brainstorm for goals and steps as the further carving of stories depends upon the goals and steps.
Stories define features, it’s necessary to think in stories than in features. Finally, end up telling the stories of the users that require reaching the goal. Splitting the stories into multiple sub-stories does not serve the priority of working on the entire story. For example, the story allows the search of an item, and sub-stories are narrowing the search with filters, selection of color, size, etc.
If multiple sub-stories are created, you would concentrate on sub stories rather than thinking of overall stories. The disadvantage of creating multiple stories is the missing narrative flow.
Another solution is to add multiple tasks under the same story, that could cover the searching of items along with the filters.
The stories are given weight as per their complexity, and accordingly, the team is assigned to complete the stories. More the weightage for a story more is the complexity and could take extra time to complete. Stories with higher weightage are taken up by the professional programmers.
Developers are responsible to decide tasks. They have all the knowledge of the framework, their third-party tools, or the required time to complete the story. During the sprint meetings, all the stories are discussed by the team members, and the tasks are noted for each. These sessions are helpful for the technical members to gain knowledge on the stories and required tasks for completion of the story.
During these sessions, it’s important to think in terms of stories rather than a task. Thinking in stories gives a holistic view of the user’s needs. As the tasks are evaluated, the technical team decides the expertise in the field for the particular task.
Once the sprint starts, the status of the tasks and stories keeps changing. As the developers, testers, and designers work together to complete the tasks, one by one the status of stories more from progressing to done and done-done.
In agile methodology, the ratio of the developers to testers is 2 or3: 1. As the tasks are in progress, the testers help the developers to test their scenarios during development. Writing automated tests, and working on manual test scenarios is the first job of the testers.
These tests are important as they check the functionality and features of stories. The main goal is to detect the bug while the stories are in the development stage.
6) Story points:
Story points are critical, as the sprint ends and retrospect’s begun, the story points plays role in deciding the complex stories. Complex stories are worked by the senior professionals, the higher the points for a story, the more complex is the story.
Backlogs are the main reason for developers to fear. The backlog stories are significant to customers and are postponed for some reason. This list is flat which ignores the purpose of stories’ existence, whereas user storyboard mapping retains the purpose. The backlogs are stories that are push to the next sprint.
As the next sprint starts the team concentrates on the backlog to get the features complete.
Many times the backlogs are not completed by the team and so the technical team is quite nervous to show their first demo.
Backlogs map the stories and ignoring them could cost you financially.
Personas are a reflection of your users. They give specific details of users such as their wants, their needs, their likes, behavior, and interest in your product. These are crucial for business. Personas are not only used by designers and developers but also marketing and sales personals.
For developers, they help understand their customers while they develop functionality for them.
Scrum masters as critical about retrospective meetings as they give insights about the process and journey followed for sprints. These meetings are attended by all, to discuss their challenges and achievements during previous sprints.
First product demos are very crucial for gather the attention of your customers. For a successful product, it’s essential to design for the product rather than work for a project. A holistic view of how to plan your product release using user storyboard mapping is rightly explained in this article.