Ats User Stories

Part of AtsGoesExtreme and the AtsDiary.

ATS UserStories tend to be small and fairly focused. Some of them are achievable in a matter of (ideal) hours. This seems to be in contrast to the ExtremeProgramming recommendations; perhaps it's because we're in the final iteration of the project and people want minor enhancements and bug fixes rather than big features. Perhaps its because most of the ATS infrastructure is already in place and we can reuse a lot of code as we implement the stories. On the other hand, perhaps it's because I, not the users, wrote most of the stories.

I wrote the stories because I want to make sure that all of the original plans for this iteration are represented. That way, if the users decide not to include something that was in the original schedule, it's their decision, not mine. But the users, for the most part, aren't asking for features that were in the original plan. Perhaps this is because they're not aware of them, or perhaps it's because they don't need them and the original planning process was flawed. Regardless, I've made stories for all of the original features, and the users will be able to decide which ones are important in the PlanningGame.

Overall, I feel like the user stories have really given the users confidence in the project and a strong sense of buy-in. I'm handing them small, easily digestible stories on index cards, not a 70 page requirements document. I'm asking them what they want, not telling them to sign off on what I've proscribed. And I'm listening to what they say, not telling them "Oh, that probably won't make it in."

In turn, the user stories have given me a sense of relief. Now I don't have to fight every feature request with the user. Now, even though I know there's too many stories to be implemented in the time available, I know I won't have to be the bearer of bad news. Now, I don't have to act as an intermediary between several groups' conflicting needs. I'll get them all into a room, Jared will tell them how much time is available, and I'll tell them how much time each story will take. When features are cut, it will be because they made the decision, not me. When difficult compromises are made, they will be compromising with each other, not seeing me as the bearer of bad news.

My biggest fear is that I'll misplace some of these cards. I'm not being facetious here; that really is my biggest concern. I love the cards' portability, but I tend to be a bit absent-minded, and I could easily drop an important card or two on the floor and never even notice, except for a vague feeling of "wasn't there something else we were supposed to do?" On the other hand, I definitely don't want to have to constantly type these things into a database. (But I should eat my words on that one -- see below.)

We use an MS Access database for KeepingTrackOfStories

The ATS UserStories are written down on a standard 3x5 index cards, ruled on one side, blank on the other. We only write on the ruled side, with a few exceptions. At the top center of the card, above the rules, is the word "USER STORY" in block letters. In the upper right is an arbitrary ID number. We keep track of the last number in the sequence on a post-it note in my office. In the lower left is "Source: " and the name of the person who originated the story, so we can go back to him if we have questions.

On the back of the card, in the upper left corner, is "RISK:" and "L", "M", or "H," for low, medium, and high. We determined the risk as described in the PlanningGame, although we did it on our own, before the planning meeting, not with the users present. In the lower left corner is "Cost:" followed by the cost of the story in ideal hours.

When I was researching UserStories, I was disappointed by the lack of examples. Therefore, for your edification and enjoyment, and as a poor archive in case I lose any, here are the stories we developed... in absolutely no order. (Well, actually, the order I picked them up off of my desk.) I've taken names off of the "source" line unless it was one of the developers. Many of the stories that weren't sourced by me were nevertheless written down by me, or had small items added by me later. As a result, even those stories that were sourced by users could sound similar to the ones I sourced.

At this time, we're still determining cost. Those cards that don't mention cost haven't been estimated yet.

2. I want to be able to create personal log entries that are viewable only to me. I would also like to restrict access to log entries to me and my manager; me, my manager, and the company for which the log entry was created; me and my group. Regardless, only people who can see my projects can see my project's log entries. Source: Al; Risk: M

10. User A leaves the office for a short time (vacation, etc.) and assigns his access privileges to user B so B can take care of A's work while A is gone. Source: user; Risk: M

11. Automatically fill in 'owner' fields when creating new projects, log entries, etc., based on the currently-logged-in user. Source: JimLittle; Risk: M

22. Only people who can see a project can see a project's action items. Source: JimLittle; Risk: M

26. A manager defines a company as being "owned" by one or more of his users. Thereafter, only the manager and the company's owners can see projects relating to that company. (Note: general company information is still visible to everyone.) This only applies to projects owned by the manager's group.

If a company has no company owner for the manager's group, then projects relating to that company are accessible by everyone. Source: JimLittle, User; Risk: M; Cost: 12 for DB + ? for app (spiked)

4. A user wants access to the system, so he finds an ATS system administrator, who enters in the user's first name, last name, middle initial, email address, username (unique), and phone number. Users may be marked as "deleted." Users may also be marked as administrators. Source: JimLittle; Risk: L; Cost: 8

3. User browses action items by responsibility and completed or not. (Possibly other filters -- check). Source: User; Risk: L; Cost: 4

1. Log entry summary. User adds a one-line summary when creating a log entry. (This summary would be useful for reporting.) Source: User; Risk: L; Cost: 4

32. A user defines "default" log entry access settings (see story #2). Whenever a new log entry is created, it starts with the default settings. Source: JimLittle; Risk: L; Cost: 8

31. A user defines "reminder period" for action items. Each action item priority level gets its own reminder period. The reminder period is in days. When an action item's estimated completion date is within the reminder period, the user is reminded that the action item is upcoming. From the reminder, the user can view the action item's project. Source: JimLittle; Risk: L; Cost: 16

28. A user marks a project as being owned by his group. (Question: can a user ever belong to more than one group?) Source: JimLittle; Risk: L; Cost: 4

23. User sets an action item's priority. Source: User; Risk: L; Cost: 4

21. Bug: New Project screen, general tab, priority drop-down is missing some entries. Source: JimLittle; Risk: L; Cost: 1

20. Bug: "My Projects" -- the Status drop-down has two "Completed" entries. Source: JimLittle; Risk: L; Cost: 1

16. Provide a box that will display the application name and version number for ATS, as well as tech. support contact info. Source: Al; Risk: L; Cost: 2

14. A manager wants his group to have access to the system, with the manager overseeing their activities. He finds an ATS system administrator, who enters the group's name and assigns the manager as its manager. The manager can then add other people with managerial privileges and also ordinary users to the group. An administrator creates users (story #4) as necessary. Groups may be marked as "deleted." Source: JimLittle; Risk: L; Cost: 16

13. Users don't initially notice 'Search' button. Make it stand out more. Source: User; Risk: L; Cost: 1

9. User assigns action item to a specific individual other than himself. Source: User; Risk: L; Cost: 4

35. Migrate existing data to new release. Source: JimLittle; Risk: L; Cost: 4

8. User generates a report with the current status of a project / multiple projects with a sentence or two describing each project and who's court the project is in. (Note: ATS will only be modified to store this data. The actual report will not be generated by ATS.) Source: User; Risk: L; Cost: 4

7. Bug: Browse Companies eg. [removed]; 'View' a company; [field] changes from '[value]' to 'DUMMY' Source: User; Risk: L; Cost: 2

5. User opens "My Companies" window and sees all the companies that he is assigned to. Then user clicks a company and sees projects of his that are for that company. This would replace the "My Projects" window. (Note: "My Projects" wouldn't necessarily be removed, but the user would use "My Companies" in preference to "My Projects." Source: User; Risk: M

30. A manager or administrator views the changes that have been made to sensitive (audited) fields in the application. Changes are recorded from the creation of a record up to the present. Source: JimLittle; Risk: M

25. When a user creates a project, he selects a project "type" or template that creates a default set of action items for the project. Source: JimLittle; Risk: M

24: Bug: "Do you want to save your changes?" dialog comes up even when no changes have been made. (Need details.) Source: JimLittle; Risk: M

19: Bug: When visiting ATS page without Java 2 plug-in installed, the wrong plug-in (1.2 instead of 1.2.2) is automatically downloaded, at least in [removed]. Source: JimLittle; Risk: M

6. Managerial log entry. Manager opens user's log and interjects a comment. Manager comments are highlighted to draw distinction from user logs. Security: User, manager. Source: User; Risk: M

12. Easily record an email message in ATS. Include details like time, date, to, from, subject, etc. plus the message. --The email is sent from another tool such as [email program]. Source: User; Risk: H

15. Restrict access to the application. Only allow people who know a user's username and password to access ATS. Source: JimLittle; Risk: H

34. User defines a default project type and its actions (for use w/ story #25). Source: JimLittle; Risk: H

29. If the user hasn't done anything with the system for 30 minutes, he is automatically logged out. Source: JimLittle; Risk: H