A user story is a short description put in everyday language to represent a discrete piece of demonstrable functionality. It can also be described as a desirement, desirable outcome by a stakeholder or a request for software to change that stakeholders desire and perceive as a necessity. User story is used to quickly document a stakeholder’s desire without giving vast formalized details. User stories are used in agile development to provide a framework where the detail of the project can be understood and added as it is needed just enough and in time.
In agile framework, the task of creating a user story is open to all. Stakeholders can write users stories without the need of business or system analyst playing the proxy role. In writing a user story an initial high level story is written and split into more stories when the development team refines the software and it becomes apparent to have additional details.
Question 1
The requirements of a user story are categorised into three often known as the three Cs: Card, conversation and confirmations. A card is a token or a little story that is used to describe text about the story and act as a reminder to conversations. A sentence is used as a card to remind users of the conversations that need to take place. The second component of a story is conversations. This is the discussion of the details and result in one or more test confirmations. Finally, confirmations form the last part of a story. Confirmations refer to the acceptance criteria that can be turned into automated acceptance tests. The automated tests are important and allow the simple and light approach to be implemented.
User stories the narrations describing the interaction of the user and the system focusing on the value the user gains from the system. Thus, the user requirements make the components of the user story. Documentation is secondary to collaboration in user stories and a highly documented requirement is not essential, rather a reminder to collaborate with the topic of the user is advocated. This shifts the requirements from system and business based to user-based. A good story must fulfil the following requirements:
- Independent and easy to implement
- Negotiable such that details are added via collaboration
- Valuable in that it provides value to the user
- Estimable: If it is too big or too vague it cannot be estimated. The stories should be small and estimable. Also, they should be completed in the shortest time possible by the team
- Stories should have a good criterion to test
Detail is added to a user story by splitting the story into multiple small stories and by adding conditions of satisfaction. When a large story is split into smaller contexts it is natural to imply that more detail has been added. Conditions of satisfaction are a high level acceptance tests that will be true after the agile story is complete.
Question 2
User stories originate from business managers, developers, and users who aspire to solve a certain problem by developing an application or software. Information on a user story is obtained from stakeholders on an ongoing basis especially as part of product backlog refinement. The contribution from stakeholders is acquired during seminars, workshops and meetings conducted for the sake of product development. Anyone can write user stories. The owner of the product has the overall responsibility of ensuring that the product backlog of agile user stories exist but this does not necessarily mean that the owner is the writer of the stories. Each team member in the development process writes the story. As a matter of fact, the writer of the story is far less important than those involved in discussing it.
Consensus on the definitions of the user stories is achieved during conversations. Conversations are conducted at any time and their nature varies from team to team. The main focus of the conversation is to discuss the details of the story, refine their meanings and create test confirmations. The product owner is crucial in this stage because they havce the last say on product vision and requirements.
The form of presenting user stories does not matter; rather the resources available depends on the method adopted. User stories can be represented in physical paper or cards, or electronically using Excel or Jira.
Question 3
Product backlog is a list of all desired product features whether they are planned to be implemented or not. Anyone can add anything to the product backlog at any instance but the product owner prioritizes it.
Question 4
Stories are allocated to different team members based on their skills and experiences. Agile development team comprises of people from diverse backgrounds. They posses analysis skills, design skills, programming skills, leadership skills and testing skills. Everyone in the team contributes depending on their skills. Stories are allocated to members based on their competence in a certain field to increase the overall productivity of the team.
Question 5
Acceptance tests are created from user stories. During iteration planning, the user stories developed are translated into acceptance tests. A story can have one or more acceptance tests and each acceptance tests represent some expected result from the system. Acceptance tests are created in every iteration so that the development team reports progress. In a whole team approach, testers are embedded in the development team and actively participate in all aspects of the project. In agile teams everyone contributes to different aspects of the project and strives to become generalizing specialists with a wider pool of skills. The fact that testers write acceptance tests does not mean that no other specialists will be involved in the process. Programmers, designers and architectures will all of them get involved in the testing process by adopting non-solo development approach and working in short feedback cycles thereby transferring new skills to their teammates.
Question 6
Requirements are verified iteratively by conducting a number of iterations of the same process and analysing the result
Question 7
Estimating time to complete a story is a practise that should be avoided in development. Measuring absolute values is not recommended; rather, comparing relative values is advised. Estimating the time required to complete a given story reduces the team to using absolute values which is what needs to be avoided. To measure stories Fibonacci sequence or series is used instead of time. A series of numbers such as 1, 2, 3, 5, 13, 15, 21 is used instead. The best way to evaluate effort is to use a degree of difficulty which assigns story points. Story points are the perfect unit for comparing relative values because they are not dependent on variations engendered by units of time. A team ranks the stories from most difficult top least difficult and calibrates them based on previous stories as a referential.
Question 8
A story is considered complete only when it has been tested and verified. When decomposing stories for Sprint Backlog an explicit task is added for Quality Assurance or User Acceptance Testing. This makes it a checklist item and any story that has not completed this task at the end of the Splint is counted as incomplete. A story is tracked to ensure that it is complete and tested as per the requirements. Experienced teams do not include testing as an explicit item because it is incorporated into their estimates and is part of the teams “definition of done”. For agile practitioners using kanbans to track stories as they progress through the workflow, unique columns for testing are provided such that stories must pass through them before being placed in the “done”. This ensures that there is a visual reminder to stress that testing is intrinsic to the process. Testing is normally defined incorporated as part of “definition of done”.
Question 9
User stories are the predominant way of expressing features on the agile product backlog. They are simple descriptions of the desired functionality told from the user’s perspective. Because there is no difference between a bug and a new feature – both describes something different to the user, bugs incomplete tasks that prevent the task from being flagged as complete/done. Thus, they can be seen as part of the work being done in iteration/sprint backlog.
Question 10
Stories that fail acceptance tests are either rejected or subjected to revision depending on the requirements of the user.
Question 11
Story boards are screen prototypes produced on paper to allow users to sequence and look at their graphic user interfaces. A storyboard is a logical and conceptual description of the system functionality for a certain functionality that includes the interactions between the users and the system. In short it tells a specific story. Story boards are put together in electronic formats or represented in on whiteboards using markers, stickers and other media.
Storyboards exist independently of the software systems they describe and exhibit numerous advantages over regular prototypes. They cannot crash, are easy to share among developers and do not give false impression that the system is already developed when it is not. Finally, feedback is easier to accommodate in story boards than in conventional prototypes.
Story boards are usually paper prototypes of the system showing a walkthrough of the scenario or a use case. They refine the scenarios of iterative development making sure that the essential pieces are in place in the intended system. It yields the requirement for the user interface and the workflow.
Question 12
Teams working on development are the one tasked with moving stuff in the board. Since the teams use the board to track work-in-progress and conduct cycle time analysis, they the once who move backlog item to and from the board.
PART II
INTRODUCTION
Requirement engineering is an essential phase of software development that translates the imprecise and incomplete needs of the users into complete, formal and precise specifications. The use of story boards and user stories is paramount in determining the exact needs of the user and customizing the solution to fit those needs.
Scrum teams, for instance, employ story boards in building great products. Investigations of this have revealed the significant role that story boards have on agile requirement management. Scrum teams are involved in activities of designing, implementing and releasing the user stories in their sprints. The different parties involved in development use story boards to meet and exchange thoughts over the requirements. Product owners play the role of representing the customer and have a clear idea of what customers and users needs and expects. On the other hand, the scrum team is a technical pool that should understand the technical intricacies of implementing a story. The two teams should collaborate to ensure that they understand the requirements in its entirety and that the development is on the right path.
Storyboarding is used by successful companies to show to coordinate building activities and come up with a better development procedures and products. Storyboarding is a powerful concept that concisely conveys information or idea. Its linear nature and visual representation allow people to quickly grasp what is communicated. It works better than any PowerPoint presentation.
In this study, we explore three case studies that illustrate the use of Story Boards for requirement management.
SCHERING-PLOUGH BIOMETRIX AND ACTIVIA ANIMATIC BY COMPANI
This is a case study involving Compani’s use of stories and story boards to make a multivitamin product with ginseng named Biometrix. It is an advertising campaign that shows a businessman on the run and displaying high energy levels as a result of the use of multivitamin supplements. Three animatics were tested and focus groups allowed choosing the best for the final TV ad. The results indicated that the focus groups voted for Biometrix Banda as the one produced for TV.
Figure 1. The first picture shows Biometrix Caleidoscopio while the second shows Biometrix Banda and the last shows Biometrix Spot TV.
In the same way, an animatic for Danone’s Activia was produced using story boards. Working from existing TV ads, ideas were tested for the Mexican market with the use of animatics. Using story boards, it was possible for Compani to produce animatics based on UK TV ads. The ads were accessed and the final animatics changed to Latin American looking ones in order to suit with the location. The first ad is an Activia UK Spot TV while the second picture shows Activia animatic. The last one shows an Activia Animatic final adopted for Latin American market.
Pygmalion Kindergarten located in Romania emphasizes the collaboration between teachers and parents to influence upon children’s behaviour and expectations. The kindergarten sets into practice the combination of traditional pedagogy and promoting global development of the child in terms of academic competencies, socio-emotional support, cognitive and psycho-motor development. The institution provides a range of services to families of children aged between 1 and 7 at least once per month together with teachers and staff and baby sitters. These services include playing activities with the children, workshops and psychological counselling for parents.
Children are divided into two groups age 1-2 and age 2-3. They then participate in psycho-educational activities under the guidance of the kindergarten psychologist. The activities optimize the children’s thinking, motion, independence, emotional and social abilities, and language. The main activity is play. Each child chooses a card with a character that represents a feeling from a table and gives a name to it.
The findings showed that the children played with the words and expressions that represent feelings. Expressions of fear, joy, sadness, surprise, shame, fury, and love were portrayed through facial and body language. Children recognised verbalized emotions and subsequently imitate them.
INTUIT SNAP TAX
Intuit conducted a game changing seminar in 2011 about how they use hand drawn storyboards throughout their business to get ideas before they invest resources and develop applications. One such idea was SNAP TAX an application that allowed users to fill their tax returns using mobile devices. Using hand written story boards, they represented the functionality of the application in a vivid and understandable manner easy for the application team to conceptualize.
DISCUSSION AND SYNTHESIS
Effective and painless agile development processes uses simple stories to represent real world scenarios. The product owner creates a simple story and shares with the development team. The development team comes back with queries around the story or a story point estimate. Fragmentation of stories into smaller bits is advisable so that functional implementation of stories having a higher business value comes before those of lower business value.
Finally in case study three, Intuit used hand written story boards to develop SNAP TAX a tax filing application accessible via mobile frameworks. The stories are split into small sections upon which acceptance tests are conducted to analyse their significance.
CONCLUSION
This report has successfully analyzed the effectiveness of user stories and story boards and their applications in various aspects of solution development. Three case studies have been highlighted and benefits described. Benefits of using story boards include a unique selling point for adopters, increased capability to customize and fit the current situation and high level analysis of the user requirements hence greater satisfaction. Challenges realized from the use of the technique include lack of specialization, increased costs of development and implementation and lack of dynamism.
References
Abhijit Chakraborty, M. K. (2012). The Role of Requirement Engineering in Software Development Life Cycle. Journal of Emerging Trends in Computing and Information Sciences.
Carol Righi, J. J. (2010). User-Centered Design Stories: Real-World UCD Case Studies. Morgan Kaufmann.
El-Attar, M., & Miller, J. (2012). Requirements Engineering: Developing comprehensive acceptance tests from use cases and robustness diagrams. ACM/IEEE International Conference on Software Engineering .
Sohail Asghar, M. U. (2012). Reuirement Engineering Challenges in Developing Software Application and Selection of Customer Off the shelf components. International Journal of Software Engineering .
