Exercise 2 ( Chapter 8 )

Exercise 2 (Chapter 8)

Q1:	Given the above XTrack story, use the process we describe in this chapter to find hidden assumptions.
A1:	Step 1: Customer view I'm the customer. How does this relate to my project? I can keep track of a story on an index card, but what if my management is in a different location and wants to see this information? What if I'm doing a project for an external customer, and stakeholders at that organization want to see the stories? This tool would allow them to do that. What business problem is it solving? How does it solve it? Index cards work great for small, self-contained projects, where everyone who needs to know the status of a story can simply walk in and look at the index cards and talk to the team. If my team is split across two or more locations, I need some way for everyone to see the stories. If my management or my clients' management wants to track the progress of stories, they could use this system. How could the system implement this and not solve the problem? Someone has to input the data into the system and keep it current. If it's not easy to use or up to date, stakeholders may still wait to find out the information some other way. Are there alternate solutions? Are there related problems? We could put the data into a simple spreadsheet and put it on a shared drive on a LAN or put a link to it on a Web site. It would have the same problems of someone needing to keep it current and would require a little more work for users to find the information.
A2:	Step 2: User view I'm a user, searching for information about a story. What are the worst and best things that can happen? What would really irritate me? Worst thing: I can't locate the story it's in the system, but I can't find it. I can't figure out how to add a new story. Two stories are similar I can't tell which is the one I want. Best thing: I can see all the stories for an iteration and all the pertinent information about them online and select the one I want from a list. Irritating: How, exactly, am I locating the story? Can I search by iteration? By name? By number? When I add the story, is the system going to do a lot of picky field validation? How can I screw up? How should the system respond? What if I enter the same story name twice for the same iteration? Does it have to be unique? Do any of the fields have special formats? Do I have to enter the timestamps myself, or are they automatically generated? How often will I do this? What will I do before and after? We'd need to update the information about a story at least twice per iteration: once to create it and once to update the status and any other information that changed before the end of the iteration. I'll probably gather information about the stories from the customer and then enter all the stories for the iteration or for the project so far. If I'm a stakeholder who just wants to find out information about stories, I might do that once or twice per iteration.
A3:	Step 3: Programmer view I'm the programmer. What's the simplest implementation that could possibly work? A form with text input fields for story number, name, author, description, estimate, iteration, timestamps, and state. This information is stored in some kind of repository: a database, an XML file. I need to know what fields are required, the size and format of them, what validation is expected.
A4:	Step 4: Identifying the mismatch How likely is the implementation to solve the business problem? Fairly likely, because this system doesn't have to handle a large volume of data or transactions. How likely is the implementation to solve the related problems? It doesn't really solve the problem of someone needing to keep the data current, regardless of where we store it. How likely is the implementation to avoid irritating the user? Respond appropriately to user mistakes? Fairly likely, as it's a simple application and users will be familiar with it. The biggest risk is for users outside the project team who want information and don't access the system as often. So we have to satisfy both "expert" and "occasional" users.
A5:	Step 5: The assumptions What information is the customer assuming we know? The system has fairly low transaction volume, used only by members of the project team, managers, and stakeholders outside the team. Team members will input the information; everyone will access the system for tracking and information. The user can find stories by iteration and name. A unique key identifies each story and avoids confusion with other stories. The user can browse and select the story from a list. The system has some way to tell stories apart.
Q2:	Identify the questions related to these assumptions that you'd ask in discussion.
1.	How many people will be using the system at any given time?
2.	Will some users have read-only access, while others are able to add and update? If the answer to this is yes, we have other questions: We must need some sort of login screen. What should this look like? What should happen if the login name or password is invalid? Are there criteria for the login name and password for example, does the password have to contain a number or special character, are special characters or leading spaces allowed in the login name, and so on? Are there just two levels of users, read-only and access to all features? Should read-only users see only the features they can use and not, for example, an Add button? Where will the login names and passwords be stored?
3.	What unique key identifies a particular story? Can two stories have the same name? Can the user select an iteration and see all the stories for that iteration? Can the user then select a story from this list? How can the user tell which story to select?