CUT AGILE. STORIES & RETROSPECT.
Luu Duong, Andy Palmowski, Michael Khodosko, Adam
Alinauskas, Manoj Khanna, Namgyal Damdul
Chapter 1: Agile Methods
Chapter 2: Story writing in Agile Methods
Chapter 3: Expert Evaluation of ID-Scrum Process and Conclusion
Chapter 4: Shortening the Feedback Loop
Chapter 5: Agile in Enterprises
Chapter 6: Agile in geographically distributed environments
Chapter 7: Agile Development in Outsourcing
TECHNIQUES FOR STORY WRITING IN AGILE METHODS
As highlighted in my first chapter “Agile Methods”, some changes would be required in ID
process or Agile process or both to integrate the two disciplines successfully. Since the
processes followed by them are contradictory – ID recommends detailed upfront work,
whereas, Agile recommends little upfront work; it becomes insurmountable to successfully
integrate them in their own forms. However, Beck (Beck and Cooper 2002) admitted that he is
“100 percent with the [ID] techniques themselves”, although he is against the process
followed by ID. He also suggested that ID “has a role to play from the moment of inception of
a project, as a way of coming up with the metaphors for the system” and he “would love to
have Alan [Cooper] on a team of mine [Beck] in that story writing”. Due to difficulty faced by
many people in implementation of “System Metaphor” was dropped it from the XP practices
in the second edition of the book Extreme Programming Explained which Beck authored. It is
the aim of this chapter to show that with certain adjustments, ID and its tools can be useful
for story writing in AMs. A process is developed to integrate ID into AMs and this process is
evaluated in a case study on an academic project. It incorporates ID tools such as Personas
and its Goals, its Scenarios with lesser upfront ID work to make it more compatible with
Scrum, the AM used in case study to validate the process. These ID tools are mainly used for
story writing in Scrum to feed into the product backlog.
A pilot case study was conducted in an academic project using XP to investigate the
shortcomings of AMs and to understand how ID can be useful in AMs. This case study
was conducted with final year computing students to implement a web project for
three months on a part-time basis. It was found from the case study that:
• While writing user stories individually was found to be not difficult but agreeing
on them as a team was found difficult.
• There was little understanding of the problem background.
• User stories alone provided some understanding about the system but it failed
to provide an overall view of the system.
• There was lack of overall vision for the project.
• When the customer representative was not available the team resorted to
making decisions on a technical basis.
• User perspective of the software was not taken into consideration.
• Changes to requirements were not made on an objective basis.
After detailed study on the compatibility of ID with AMs involving many months of
research, and based on the above findings and observations of the pilot case study, a
process integrating ID into Scrum was devised to overcome the above shortcomings.
The process is described in the next section in detail.
Scrum focuses on the project management of the software projects, but when
integrated with ID approach it could facilitate development and management of
requirements – in particular user requirements. Requirements developed from
personas’ goals and scenarios feed into the product backlog of Scrum which in turn
facilitates frequent prioritization of requirements based on the perceived needs of
the personas. In this way, ID and Scrum can complement each other to improve
requirements development and management. The personas created in this process
can assist the Product Owner (PO) in making objective decisions during development
when the customer representative is not available. The following are the activities in
the ID-Scrum approach.
Brainstorm Problem Background & Short Interviews:
Traditionally, ID follows a very comprehensive approach involving detailed user
research prior to design. Such comprehensive approach is not compatible with AMs as
discussed above. In place of detailed user research, a problem background
brainstorming session is held with all stakeholders. As when issues are identified
during brainstorming, on-the-fly questions might be asked to the stakeholders. In this
session, all stakeholders including users, customer, domain experts, and developers
should take part and answer the questions that may arise, so that everyone’s views
are considered in developing problem overview. The ID-Scrum process is displayed in
diagrammatic form in Figure 1 below.
Problem Background &
Short Interviews For each Persona
Select Primary Persona
Write User Stories
A Process for Story Writing with ID Techniques
Figure 1 - The ID-Scrum Process
Each is encouraged to put forward one’s own perspectives and issues relating to the
project. Important elements of the project are identified during the discussions on
the problem background which can be led by the PO who will make the final decision
in cases of conflicting ideas or disagreements. Any artifact produced may be used for
reference by the stakeholders later. The users and customer should also answer
questions raised by the PO and developers as much as possible. Discussions might lead
to discovery of issues which might need to be further explored with the stakeholders.
In such cases exploring the issue through short interviews could be useful. Short
interviews are beneficial as Cooper et al. (2007) suggested that “interviews as short
as one hour can be sufficient gather the necessary user data”. This session provides
an opportunity for all stakeholders to gain a common understanding of the problem
overview. With this common understanding should facilitate the stakeholders to agree
on a high level project vision or goal. A vision could include project’s context i.e.
project’s end goals or outcomes, project’s objectives, project’s scope etc (Augustine
2005). The agreed vision should be written or drawn on a wall-chart and posted on
the wall for everyone to see throughout the project.
It is likely that a rough idea of different roles could be achieved from the above
problem discussion and short interviews. These abstract roles should be further
explored through discussions with the stakeholders, particularly users, to identify key
personas. It is also important to ask stakeholders if they can think of any potential
personas which have not been identified. If there are, their details should be explored
with stakeholders. During the discussion, information relating to users’ behaviors for
creating personas gained from the users, while information relating to the business
environment should be explored with the customer. Other members should play
“devil’s advocate” and ask questions to the users and customers why they want
something and how do they know it is good for them or any particular persona. In this
way, effort should be made to minimize prejudice and error within this short period
of persona exploration. The recommended number of personas is between two and
six, but this depends on the project. Suitable persona pictures must be selected for
each persona so that the team gains empathy with the personas to be real users.
Persona details such as name, habit, age, and profession are explored and recorded
on a flipchart for each persona based on discussion, interviews with users and other
stakeholders. Persona flipcharts must be which is made visible, ensuring that
everyone can see them during development. The team should refer each persona by
their agreed name for any future reference so that they gain empathy with each
persona as if they are designing or developing for the real users.
Generally, each persona has a couple of goals they want to accomplish and which
should be satisfied through his interactions with the system. The goals should
represent what each persona wants to achieve at the end of using the system. They
are different from tasks and they are expressed at a higher level of abstraction than
tasks. A goal is an end condition whereas tasks are intermediary steps (Cooper 2004).
It is important to separate the two as there could be a number of ways to reach a
particular goal. Goals should be identified from information gained in the problem
background discussion, short interviews with the users and other stakeholders.
Identified goals should be recorded along with the persona detail charts which are
made visible to all.
Scenario is a narration of situations or circumstances under which users accomplish
their goals. Daily scenarios are identified as these are considered “most useful”
(Cooper 2004). Other scenarios should be used but priority should be given to the
daily scenarios. In defining scenarios, it is important to focus on personas’
interactions with the system under different circumstances rather than focusing only
of their tasks. Although all possible scenarios for a persona using the system are
considered but only the most relevant scenarios should be selected. Scenario
information should be written on the individual persona flipcharts, which is displayed
on the wall for everyone to see.
Select the Primary Persona:
A primary persona is selected by the stakeholders from the identified group of the
personas agreed. Stakeholders should understand that to be a primary persona should
have his own interfaces as other persona interfaces cannot satisfy him. This is
because his needs are most important and it is unlikely that interfaces built for
someone else can satisfy his needs. Based on this principle, primary persona should be
selected. Usually one primary persona is selected but up to three personas may be
selected if required. More than three personas are not recommended as the problem
becomes too large. The primary persona is the most important persona and the
system designs and needs are mainly influenced by him.
Write User Stories:
Stakeholders can use the personas and associated details to identify user stories for
the project. The persona goals and scenarios can be a basis for some user stories.
Initial communication with customer and users can provide information about their
needs, which can lead to user stories. User stories for the primary persona should be
written first, as requirements relating to him are most important, and any similar or
repetitive user stories for other personas may be avoided or reduced. All agreed user
stories combine to form the initial product backlog. User stories are estimated by the
developers in consultation with other stakeholders.
Prioritize User Stories:
PO is responsible for prioritization of the user stories. His choice and decision for
prioritization should be guided by the primary persona. Naturally, user stories relating
to the primary persona should have the top priority, which helps to guide the overall
prioritization. He can listen to the views of the team members but only he has the
right to prioritize or reprioritize. The prioritized user stories should be displayed on a
large chart which is the physical representation of the product backlog.
In the Sprint Planning Meeting, a specific sprint goal is agreed by stakeholders. The
team selects the user stories from the top of the prioritized backlog to achieve the
agreed sprint goal through implementation. The selected user stories are broken down
into smaller tasks for implementation during the sprint. These tasks form the sprint
backlog. As the stories are examined in more detail the tasks are estimated by the
team with the help of the customer. In Daily Standup Meeting, team members address
three questions - what did I do yesterday? what will I do today? and what
impediments got in my way? which help to identify progress and roadblocks. Team
members should commit themselves to take responsibility for specific work in front of
their peers. This meeting should not be used for problem solving or detail discussions.
Usually this daily meeting lasts only for 15 minutes. After daily meeting every day,
the team engages in the development of the software.
The emphasis of this process is on identifying more accurate user needs through an
investigation of the personas in an agile manner requiring little extra time and
resources. By having project specific user representations, in the form of personas,
we can improve the identification of user requirements, requirements prioritization
and ultimately requirements management without incurring high costs. The next
section discusses the case study which was used to test this process, along with
observations made and feedback from the participants.
THIS IS A PARTIAL CHAPTER … FOR COMPLETE BOOK
PURCHASE VISIT US ON http://rapidbooks.ca/store.