Part of AtsGoesExtreme and the AtsDiary. See also StatusReports and AtsSpitAndPolish. ----- ExtremeProgramming suggests that documentation be kept to a minimum be driven by UserStories. The reasoning, I believe, is that the code and the tests are the documentation (see TheSourceCodeIsTheDesign) -- functional tests document the intended functionality of the program, and the UnitTest''''''s and source code document the design of the program. For the most part, I agree with this philosophy. In my experience, documentation becomes out of date as soon as it's written on an active project. It requires that developers understand that SourceCodeIsForHumans and actively treat it as documentation, and it also implies that you're writing more readable code, not just moving the documentation into comments. The approach of documenting most things with code and driving the rest with UserStories makes sense to me. However, I think it breaks down when it comes to communicating with the GoldOwner''''''s. On ATS, the GoldOwner''''''s aren't users of the product and they don't participate in PlanningGame meetings. As a result, they don't get the WarmFuzzyFeeling that the GoalDonor''''''s get about the project. To provide this feeling, I think that regular StatusReports and visible SpitAndPolish is crucial (see AtsSpitAndPolish for more about this second component). On ATS, I intend to provide weekly status reports. There's two versions: one for the GoalDonor''''''s and one for the GoldOwner''''''s. They're both the same, except that the GoldOwner''''''s' version includes budget figures along with time estimates. The first status report took me an hour and a half to produce and didn't affect the functionality or readability of the application at all. So by some standards, that time may have been wasted. But in return, I received glowing "thank you" messages from both of the GoldOwner''''''s on the project. In my opinion, the time was well spent. Here's the status reports I used on the ATS project. I've made edits where necessary to protect my client. ----- ''6 March 2000'' Accomplished last week: * Project (re)launch * Set up work environment and staffed project * Reviewed and prioritized user needs (see below) * Researched high-risk problems * Estimated times and determined programming tasks Upcoming this week: * Restrict access to ATS using [x]. (#15) Estimates: * Sunk setup costs: 1 wk @ $$$ (estimate; hours for [developer] are not available) * Engineering time completed: 0 hrs * Est. time remaining in iteration 4: 110 hrs (3 wks) @ $$$ * Est. iteration 4 release: 27 March 2000 * Est. time remaining overall: 171 hrs (4.5 wks) @ $$$ * Est. final delivery: 5 April 2000 * '''Total Cost (estimated): $$$''' '''''Estimates have an error range of 10%.''''' '''Notes:''' This week, we identified the users' needs, documented them as "user stories," and prioritized them. We've planned for two iterations. Since the first phase of this project was completed in three iterations, these iterations will be called "4" and "5". Iteration 4 will take 324 developer-hours +/- 10% (about three weeks) and iteration 5 will take 183 developer-hours +/- 10% (about a week and a half). We divided the work into two iterations to ensure that the most valuable features were available as quickly as possible. A large number of less-important stories were identified but couldn't be implemented in the scheduled time. These stories can be implemented in additional iterations if more time becomes available. In addition, if business needs change, any ''unimplemented'' story can be removed from the schedule and replaced with a new one of equivalent time cost. Please continue to identify your needs and document them as stories so they may be considered. The following stories will be implemented in iteration 4. The number is an ID that you can use to refer to the story. * Restrict access to the application. Only allow people who know a user's username and password to access ATS. Authenticate using [x]. (15) * 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. This only applies to projects owned by the manager's group. If a company has no company owner for the group, then those projects are accessible to everyone in the group. General company information remains visible to all ATS users. (26) * Automatically fill in "owner" fields when creating new projects, log entries, etc., based on the currently-logged-in user. Automatically populate "My Projects" window. (11) * 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 priviledges and also ordinary users to the group. A database administrator creates users as necessary. Groups may be marked as "deleted" by an administrator. (14) * A manager or administrator browses a list of groups, filtered by group name, manager name, and deletion status. The same fields are shown in the group list. (36) * A user marks a project as being owned by his group. This is a required field. (28) * Only people who can see a project can see that project's log entries. (38) * Only people who can see a project can see that project's action items. (22) * Increase max length of action item title to 128 characters. (37) * Bug: "My Projects" - the Status drop-down has two "Completed" entries. (20) * Bug: New project screen, general tab, priority drop-down is missing entries. (21) * Bug: Browse companies, e.g., [x]. View a company. [Field] changes from [value] to "DUMMY". (7) The following stories will be implemented in iteration 5: * If the user hasn't done anything with the system for 30 minutes, he is automatically logged out. (Change will not necessarily be shown until next user action, which would pop up the login window. On successful login by the same user, ATS will pick up where it left off.) (29) * A user marks a log entry as intended for a manager report, a company report, and/or a group report. (2) * User browses action items, filtered by responsibility, priority, and completed or not. Similar information is displayed in results list. (3) * 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 [x]. (19) * User sets an action item's priority to Low, Medium, or High. (23) * User A leaves the office for a short time (vacation, etc.) and assigns his access priviledges to user B so B can take care of A's work while A is gone. * A user defines a "reminder period" for action items. Each 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. If there are any details of these stories you would like changed or clarified, please contact a member of the ATS team as soon as possible so we can make the change before the story is implemented. ----- [Note: For the remaining status reports, I'll be posting the version ''without'' budget figures that is sent to GoalDonor''''''s. The only difference is the figures, and I'd have to edit those out anyway.] '''ATS Status Report''' ''Tuesday, 7 March 2000 - Monday, 13 March 2000'' Accomplished last week: * Worked on restricting access to ATS using [x] authentication. (#15) * Added [developer] to the project and set up another office. Upcoming this week: * Finish restricting access to ATS. (#15) * Investigate problems with [x] authentication '''(high risk, see below)'''. * Company ownership and project-level access restrictions. (#26) * Automatically populate 'owner' fields and 'My Projects' window. (#11) Estimates: * Engineering time completed: 107 hrs * Est. time remaining in iteration 4: 218 hrs * Est. iteration 4 release: 27 March 2000 ''(at risk - see below)'' * Est. time remaining overall: 406 hrs * Est. final delivery: 5 April 2000 ''(at risk - see below)'' ''Estimates have an error range of 10%. See new information about schedule risks below.'' '''Notes:''' This week, we started development work on iteration 4 of ATS. We're progressing well thus far, but there's a few big risks on the horizon. The first risk is developer schedules. One of our developers has commitments to another project which has taken half of his time this week. In the future, that project is expected to take about 20% of his time. Our original schedule estimates were based on having three full-time developers, so this could result in iterations being delivered later than expected. The cost of the project, however, will not increase. The second risk we're facing is [x] authentication. We've tried several different approaches without much success. Earlier this week, we identified a solution that seemed to work, and it tested successfully for several days. However, today (Monday), our automated tests signalled that authentication was no longer working. We had made no changes to that part of the program, and hadn't even been working in that area. We're investigating the problem, but without any luck so far. Due to the problems we've had with [x] and the unknown factors that are involved, I'm classifying [x] authentication as '''high risk'''. We'll continue investigating [x] for the remaining amount of time allotted to it. After that, we may have to either postpone [x] support or remove another story from this iteration to make more time for [x]. This could impact the cost and schedule of the project. In the upcoming week, we'll look into our options further. I'll present the results, as well as any decisions that need to be made, in next week's status report. ----- '''ATS Status Report''' ''Teusday, 14 March 2000 - Monday, 20 March 2000'' Accomplished last week: * Finished: Restrict access to ATS using [x] authentication. (#15) '''(but see below)''' * Finished: Automatically populate 'owner' fields and 'My Projects' window. (#11) * Finished: Project priority drop-down bug. (#21) * Finished: Project status drop-down bug. (#20) * Ongoing: Company ownership and project-level access restrictions. (#26) * Ongoing: Enable authentication for Java on development web server. Upcoming this week: * Enable authentication for Java on development web server. ([Dev2] will be doing this; see below) * Company ownership and project-level access restrictions. (#26) * Selecting/browsing groups. (#36) Schedule: '''(estimates have changed; see below)''' * Engineering time completed: 242 hrs * Est. time remaining in iteration 4: 219 hrs * Est. iteration 4 release: 4 April 2000 * Est. time in iteration 5: 252 hrs * Est. final delivery: 18 April 2000 ''Estimates have an error range of 10%.'' '''Notes:''' We finished our first and biggest story this week: ATS security with authentication. Authentication turned out to be a bigger problem than we expected, taking 66 hours rather than 24. [Dev1] was a huge help in this area; without him, we'd probably still be working on it. Authentication still isn't quite done; although we've got it working on the client and on [Dev1's] server, configuration problems with the development server are preventing it from working there. [Dev2] is working on resolving those problems, which will save us from any more overage on the authentication work. Thanks, [Dev2]. The other big task we performed this week was to calibrate our initial estimates. I created our initial story estimates based on the time required in the first three iterations of ATS. Unfortunately, I thought in terms of how long the team took when they were focused on the task and after they had been working on the project for three months. I didn't adequately account for the time spent in design meetings, code reviews, or explaining the code to new developers. We're using a practice called "pair-programming" that reduces these costs, but it didn't reduce them as much as I had hoped. As a result, when we calibrated our estimates (compared actual time spent to estimated time spent), we found that we had under-estimated the total time to implement the stories by about 30%. This has increased the schedule and cost estimates of the project accordingly. The new estimates are shown above. If the new estimates are too high, we can postpone some of the stories planned for this release (see my first status report for a list of the stories we're implementing). If you want to take this route, please let me know as soon as possible. Let us know the maximum amount of time we can spend, and I'll arrange a users' meeting so they can decide which stories are most important. ----- '''ATS Status Report''' ''Teusday, 21 March 2000 - Monday, 27 March 2000'' Accomplished last week: * Finished: Company ownership and project-level access restrictions. (#26) * Finished: Group creation and modification. (#14) * Ongoing: Selecting/browsing groups. (#36) Upcoming this week: * Work with [dev1] and [dev2] to enable authentication on dev. web server. * Log entry access restrictions. (#38) * Action item access restrictions. (#22) * Group ownership of projects. (#28) * Increase max length of action item title to 150 characters. (#37) * Fix cosmetic company browsing bug. (#7) * Iteration 4 Release! * '''Stakeholder planning meeting for iteration 5''' Schedule: * Iteration 4 Release: 4 April 2000 * Iteration 5 Release: 18 April 2000 Notes: Early next week, we'll be releasing ATS iteration four. This release has all of the major security requirements identified by the users: Authentication, restricted access to projects, log entries, and action items, and managerial control of company assignments and related security. There's also several bug fixes and minor features. Before starting the next release, we'll be holding a planning meeting with the users to review and update the features to be included in iteration 5. If you have any new features that you would like to have considered in that meeting, please contact a member of the ATS development team as soon as possible. See the first ATS status report for the currently-planned list of features. At this time, there's only one major risk on the horizon: Getting authentication to work. [Dev1] and [dev2] will be working on that problem this week. (It appears to be a configuration issue with the server we're using.) Other than that, development is proceeding very smoothly. We're on track to deliver on April 4th as planned. ----- '''ATS Status Report''' ''Teusday, 28 March 2000 - Monday, 3 April 2000'' Accomplished last week: * Enabled authentication on development web server. (Thanks to [dev1] and [dev2] for their hard work on this issue.) * Finished: Log entry access restrictions. (#38) * Finished: Action item access restrictions. (#22) * Finished: Group ownership of projects. (#28) * Finished: Increase max length of action item title to 150 chars. (#37) * Finished: Selecting/browsing groups. (#36) * Finished: Fix Java plugin installation bug. (#19) * Stakeholder planning meeting for iteration 5. Upcoming this week: * Fix action item bug. (#101) * Release iteration 4. * Log entry reporting flag. (#2) Schedule (revised; see below) * Iteration 4 Release: 7 April 2000 * Iteration 5 Release: 3 May 2000 Notes: We had our iteration 5 planning meeting today. In that meeting, the users decided to postpone the iteration 4 release by three days in order to resolve two critical bugs. We also identified the stories to implement in the iteration 5 release. These stories are listed below. Overall, the scope of the project has increased by about 90 hours. If this is too large, the users have identified one 72-hour story that could potentially be dropped. (Story #31, the last one listed below.) The schedule for iteration five has also increased due to our team being reduced from three developers to two. [Dev3] will be leaving ATS to work with [dev4] on [project] at the end of this iteration. [Dev3]'s been a great member of the team, hard-working and easy-going, and we're sorry to see him go. But I'm sure [dev4] will be happy to have the help. Best of luck, [dev3]. Here's the new stories that were added on to iteration 4: * 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 [browser]. ''(19)'' * Bug: Action items aren't saved when project is saved. (Create action items from edit project window.) ''(100)'' Here's the stories that are scheduled for iteration 5, in order of importance: * User marks a log entry as for himself only; for himself and his manager; for himself, his manager, and the project's company; or for himself and his group. ''(2)'' * User browses action items by responsibility and whether they've been completed or not. ''(3)'' * Optimize size of ATS client .JAR file. ''(101)'' * Don't allow [info] to be viewed by users. Instead, provide [alternative approach]. ''(102)'' * User A leaves the office for a short time (vacation, etc.) and assigns his access priviledges to user B so B can take care of A's work while A is gone. ''(10)'' * A user defines a "reminder period" for action items. 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. ''(31)'' ----- '''ATS Status Report''' ''Teusday, 4 April 2000 - Monday, 10 April 2000'' Accomplished last week: * Finished: Fix action item bug. (#101) * Finished: Release ATS iteration 4 to users. * Finished: Train select users. * Finished: Plan iteration 5. * Ongoing: Create action item browser. (#3) Upcoming this week: * Create action item browser. (#3) * Implement user proxying. (#10) Notes: We released ATS iteration four last week, two days ahead of schedule. It's available at: [URL] Overall, the rollout went smoothly. We took advantage of the additional time to train about twelve users. The biggest demand at this point is for reports. We've decided not to integrate reports directly into ATS at this time since we have another tool that allows us to create reports much more economically than in Java. As a result, [dev] will be working with the users to create the reports they need. ATS has been working smoothly so far. The biggest problem to date has been with the web server's availability. It was down most of the day Friday and Monday. This timing is particularly bad, since it's hurting our momentum with the users. We're looking into the possibility of using a server that we have more control over to host ATS. Since most of the week was spent in tasks surrounding the release, I don't have any new schedule or budget estimates. This week, we'll get back to hard-core development. I'll have the latest numbers in my next report.