- Managing the Product Backlog
- Collaborating to Groom the Product Backlog
- Ranking User Stories with a Dot Voting Method
- Illustrating User Stories with Storyboards
- Sizing User Stories Using Comparison
- Splitting User Stories Along Business Values
- Tracking User Stories with a Collaboration Board
- Delivering a Coherent Set of User Stories
- Planning Work with User Stories
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Illustrating User Stories with Storyboards
As experience teaches, stakeholders love to envision the software from the user interface standpoint. As a result, often they specify how the software should work, rather than just what it is supposed to do. This is why illustrating user stories with a storyboard is so efficient.
Storyboards, as we know them today, were developed at the Walt Disney Studios in the 1930s. The first storyboards evolved from comic book-like story sketches. They were used to “preview” an animation before a single animated cartoon was produced.
Figure 5.2 shows an example of a storyboard for an animated film. Not only does a storyboard make possible a dress rehearsal of the final product, but also by posting it on the wall, it elicits early feedback and encourages quick, painless editing, leading to significant savings in time and resources.
)
Figure 5.2. An example of a storyboard for an animated film.
For the general public, a storyboard means drawing pre-production pictures for video production, animation, and film making. Unfortunately, too few know that storyboarding also applies to software development. It helps to illustrate the important steps of the user experience.
It is tough to capture the big picture without visually depicting the user story. Explaining requirements from the perspective of the user interface helps to turn unspoken assumptions into explicit information. In addition, explicit information helps stakeholders think and communicate effectively. To keep up a healthy conversation between stakeholders, the product owner, and the development team, each user story should be enhanced with a storyboard. During specifications, the screens required to illustrate the user story are roughly sketched, either on paper or through the use of computer-based software.
Do not expect the storyboard to be a visual prototype that looks like the final user interface. It is an artistic rendition in which many details are missing. A storyboard is a low-fidelity visual aid that communicates the visible behaviors of a user story.
The process of visual thinking enables stakeholders and the product owner to brainstorm together, placing their ideas on storyboards and then arranging them in a structured way. This fosters more ideas and generates consensus within the group. The reason for the usefulness of a storyboard is that it helps stakeholders, as well as the development team, understand exactly how the user story will work. It is also more cost-effective to make changes to a storyboard than to an implemented user story.
The simplest technique for creating storyboards is paper prototyping 1 2 It involves creating rough, even hand-sketched, drawings of the user interface to use as throwaway prototypes. All interactions within the prototype are simulated. Although paper prototyping is sketchy and incomplete, this simple method of communication with stakeholders can provide a great deal of useful feedback that can result in the design of better user stories. Figure 5.3 demonstrates how you can easily sketch ideas, test them almost instantaneously with stakeholders, and get rapid feedback on what does and does not work.
)
Figure 5.3. An example of a paper prototype.
After collecting and visualizing ideas on how the user interface might look, when there is a consensus on the user experience, it is desirable to keep an electronic copy of the storyboard for future reference. The simplest technique is to transform the paper prototype into a low-fidelity computer-based storyboard. The storyboard can then be used as a visual illustration of the user story, which will be shared with the development team. It is important, however, to make sure that you do not use a software tool that attempts to make the user interface similar to the final product. These high-fidelity tools encourage precision, and specifying all the details is time-consuming and deemed inappropriate at this time.
Figure 5.4 shows a low-fidelity computerized storyboard for the following user story, “As a student, I want to select a transit fare so that I can buy it.”
)
Figure 5.4. A computerized low-fidelity storyboard.
Designing the storyboards is always the responsibility of the product owner. He may nonetheless be assisted by the team members while performing his duties. For example, business analysts can help to complete the computerized storyboards. However, this activity is essential for obtaining a healthy backlog, and the product owner must be fully involved.