VIEWS: 14 PAGES: 9 POSTED ON: 7/9/2011
ROUGH CUT AGILE. STORIES & RETROSPECT. SERIES Luu Duong, Andy Palmowski, Michael Khodosko, Adam Alinauskas, Manoj Khanna, Namgyal Damdul Contents 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 2 TECHNIQUES FOR STORY WRITING IN AGILE METHODS INTRODUCTION 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. 3 • 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. ID-Scrum Process 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 4 are considered in developing problem overview. The ID-Scrum process is displayed in diagrammatic form in Figure 1 below. Interaction Design Problem Background & Short Interviews For each Persona Brainstorm Goals Identify Personas Brainstorm Scenarios Select Primary Persona Write User Stories Product Backlog Prioritise Stories A Process for Story Writing with ID Techniques Figure 1 - The ID-Scrum Process 5 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. Identify Personas: 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. Brainstorm Goals: 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. Brainstorm Scenarios: 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.
Pages to are hidden for
"AGILE. Stories _amp; Retrospect"Please download to view full document