Projects

A project is the basic unit of experiencing the system (as described in ProjectPlanningModule). It serves as the container for teams, user stories, iterations, etc. Basic data about a project is the title and description.

A Project Manager or Admin user can add projects. This sets up the basic infrastructure needed for a project.

A Project Manager (or user with permissions to more than one project) can switch between projects (***how should this happen in the UI? A dropdown selector? A "project" tab that only shows if you have access to more than one project...other ideas?).

Planning

See ProjectPlanningModule

Progress Dashboard

This section is meant to capture information about the various report screens that are useful for managing a project and giving team members (including clients) a glimpse of current status, preferably with visuals, where possible.

1. Burndown chart (perhaps associated with 4): This is a very useful tool for knowing at a glance how a team is doing relative to its goal for an iteration. Burndown chart shows the total estimated hours remaining during each day of the iteration, updating as the team updates the hours left to do on tasks in the iteration. The chart usually shows the ideal rate of burndown (ie from total estimated hours down to zero over the number of days of an iteration) and then a bar or line of the hours remaining.

2. Task status: Summary of an iteration (current by default, or chosen by user via dropdown list of iterations). It shows: the burndown chart, start and end dates, and the list of user stories in the iteration with the story points, estimated hours, and "to do" hours for each story (later two are generated from some of tasks). At ifPeople, we have found this the most frequently used screen in Rally. The page provides other features as well (re-prioritizing, adding new stories, drill down to tasks, etc), but the single page report of where we are as a team and the ability to get to information to know what to do is key.

3. Defects status: the iteration status (or somewhere else?) indicates the defects per story within an iteration. Includes total number as well as the list of linked defects.

4. Test status. Show the status of tests passed / failed per user story per iteration. Drill down to see which tests have passed / failed.

Teams

A given project will need to track information about the team that will be working on it. Team members include roles of client, developers, project manager (and admin). A project manager or admin can set permissions for a user. It should be easy to add people to a team (which should correspondingly handle the permissions and access they need to various spaces used by project - Trac/Cluemapper, svn, etc). Additionally, this area serves as a tool in planning in the sense that it gives you a view of capacity of each team member as well as how much they have assigned (enabling more efficient distribution of tasks and planning for distributed teams). Ideally, this would extend to the cross-project team level as well.

Permissions and roles:

- Basic user: can have permissions to "view" or "view and edit" a project. Appropriate for developer or client user. - Project manager: can add projects, set team from given users, view and edit project. - Admin: can add projects, add users to system.

1. Team member capacity: a team member should be able to designate a capacity for a given time range (per day, per week, per iteration?). The team member would be able to indicate capacity per time period in a total number of hours. Note: if this is done globally (ie "my total capacity for work"), then we need another means of designating what the capacity for a particular project is; alternatively, if we allow capacity to be done at project level, we should provide a report/screen that shows the sum for the given user of all their planned capacities.

2. Team status screen: This report shows the team members in a project/iteration and their capacity vs scheduled/assigned tasks hours totals.

3. Cross-team status report: reports on capacity and availability would be able to be generated for a whole company (note: this will probably involve assumptions about how hours are spent across an iterations or whatever time period the capacity is measured with - as long as the assumptions are transparent, some tool for cross-team planning is better than nothing!).

User Stories

For Jazkarta/ServerZen, we made a very crude implementation of linking stories to tasks, but would like to revisit this approach to make one that is more robust and future-proof.

1. Project manager creates stories with rough estimates in days. Alternative: rough estimates are in "story points" (a la Scrum), which provide a relative size measure.

2. Project manager or client can add additional information to story in form of Test Cases (Acceptance Tests). These provide the additional details beyond the general/short user story. Most of these become automated functional tests.

3. Developer creates tasks (in Trac-speak "tickets") with estimates in hours, and create a reference to a particular story. Ideally one could create these tasks directly on the story itself (auto-creating the link between task-story). Tasks should have a category tag or dropdown (ex: UI, design, development, testing)

4. User can see for a given story all of its associated tasks and the total number of estimated hours, to see if this matches up with the original estimate in days (Gerry - if you want to compare, days is too vague, should be in hours like task estimates).

5. User can see a list of stories for a particular iteration (in Trac-speak "milestone"), with columns including:

1. Rough estimate in days / story points (at the story level)
2. Total hours estimated (sum of task estimates)
3. Actual hours booked so far (Gerry - prefer not to have this here, too much emphasis on actual can be a bad thing)
4. Time remaining (sum of time remaining on each task)

6. Users can drill down from the story overview page to the individual tasks to see their estimate, time remaining and actual hours. The way XM does it works pretty well, but this should all be ajaxified for a more faster and more responsive UI.

7. User stories can be prioritized. Use stories should be able to be prioritized by "bucket" (ie per iteration and in the backlog). Priorities could happen based on relative placement or by assigning numbers to each story (free form entry). This column should provide a sorting ability for any view (ie iteration summary).

8. Defects: have very similar use case to user stories. If we are going to separate them, then we need to be able to link defects to User Stories (ie show defects related to a particular story).

Tasks

Tasks can be logged on a user story (tasks do not need to exist independent of a user story) and are where the actual hours estimates for work to complete a user story are recorded. The task needs a title, description, hours estimate, field to record hours completed and remaining time (any of these fields can integrate with a separate TimeTrackingModule? ).

1. From a user story, team member can add a task. The task is autolinked to the user story. Tasks may be for development, testing, manual tests, migration, communication, etc.

2. User story view shows estimated hours as the sum of all estimates on the tasks.

3. Task workflow: At minimum, we need tasks to be defined/new, in progress, and complete. Seems that track also has assigned and accepted. Trac tasks do not have the notion of "in progress", which is very useful to be able to tell at a glance what team members are working on currently.

4. When tasks are accepted (or assigned?), the estimated hours update the team member's capacity hours.

Test cases

Test cases (acceptance, functional, or other tests) are essential for clarifying the details of user stories. These can include exact procedures that must work and the specifics which a client wants in order for the work to be accepted.

Minimal test case, what is used in most cases: title, linked user story, description

Detailed test case: add priority (useful, important, critical), pre-conditions, steps (inputs and expected results), and post-conditions.

Test results can be logged against the tests, which document: date of test, tester, result (fail = default, pass, error, inconclusive, and notes (and related Test Case).

Team member (product owner, client) enters test cases to clarify details on a user story.

Scenario #1: Project manager records test results on a test case while reviewing the site with client. As the site is demo'ed the PM can record if the tests passed or failed. Developers will use the failure notes to make corrections.

Scenario #2: Tester goes through acceptance tests before story is marked complete and ready for review by client. The tester records which tests passed or failed.

There should be a way to see how many test cases have passed / failed from an iteration dashboard.

Time tracking

Rocky has already started working on ClueTimer which is a Django app. Clayton has already started working on Sixieminutes which is a Pylons app.

Both have the goal of existing as a standalone app but with the ability to integrate with Trac.

See ClueTimerReporting for use cases.

1. User wishes to book hours for a given task. User goes to the timetracking app (TTA) and supplies a project ID. TTA would query Trac for that project's tasks. User selects the task to which he wishes to book hours. Hours are booked in the TTA and also updated in a read-only data field in Trac's database.

1. In addition to project ID, user optionally supplies a milestone or user id to filter the result set of tasks that are returned to choose from. Presumably, the user will usually only be booked against tasks which are assigned to him, so maybe this should be the default. However, sometimes there may be more than one person booking hours on a task that is only owned by one person. Trac only allows a single person to be owner of a task.

1. Additionally, the user enters the "time remaining" for the task while booking the time. This updates the task status. If the time remaining is 0, the task is marked as completed.

1. User can also manually edit the status of a task while booking time.

1. User can also start / pause / stop time on a task, and can alternate between tasks. So for example, task A might have 33 minutes recorded, then user switches to task B, so time on task A is paused and time on task B is started.

2. User can see total time booked for tasks on the project and can get a timesheet for the project bookings.

3. User can see total time booked for a date range. User can select a date range and project (or specify "all projects") and a timesheet of bookings is generated.

4. Project manager can generate a report of summarizes of time booked by user in an iteration of a project. Drill down to the team member time logs.

5. Administrator can generate reports of time by selecting any user (or all) from dropdown, specifying time range, and selecting a project (or all) from dropdown.

Search

Search should be possible for the various project assets in place. Search should default to a project-specific search. Search results should offer a cross-project option (which respects the user's permissions to projects)

Import/export data

Making the system appealing to a wider audience will be helped by enabling people to (a) "move in" more efficiently and also (b) get their data out for other users (ie spreadsheets). This will mean that import/export abilities are very useful features.

Import of data:

(a) Provide a template for data to be imported. Data to be imported would include (i) user stories, (ii) test cases, (iii) defects. (b) Handle import from common systems people might be migrating from. For example, Rally. For this story, we need to investigate if a complete dump of data can be obtained via a script and the web API or if we have to rely on the UI-based exports (project specific, limited data).

Export of data:

Particularly useful parts to export are (a) the backlog, (b) all user stories and defects, (c) the current iteration's status. This would provide a simple dump to csv for later manipulation in a spreadsheet.