Ats Status Report
Ats Status ReportPart 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 UnitTests 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 GoldOwners. On ATS, the GoldOwners 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 GoalDonors 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 GoalDonors and one for the GoldOwners. They're both the same, except that the GoldOwners' 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 GoldOwners 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:
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.
[Note: For the remaining status reports, I'll be posting the version without budget figures that is sent to GoalDonors. 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:
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:
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:
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:
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:
ATS Status Report
Teusday, 4 April 2000 - Monday, 10 April 2000
Accomplished last week:
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.
EditText of this page
(last edited August 16, 2014)
or FindPage with title or text search