Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
Defining a Project Methodology, Part II

A reader brought up the point that going "too" light and agile makes it very difficult to get other developers involved in the project or to hand the project off to a whole other development team.  Furthermore, how are requirements efficiently tracked at all if we just have a few simple checklists to start with.  In other words, how do we ensure the "survivability" of the project if the key people involved get hit by a bus and just how much documentation is appropriate?  There certainly has to be enough useful documentation for a new developer, or team, to pick up the project, understand how it works, and make a change to it without being completely afraid of breaking something.  Furthermore, there has to be enough useful documentation for both the client and other stakeholders to know the general scope of the project, know what requirements have been implemented, know what changes have been requested, and what requirements are left to be done.
Defining Useful Documentation

The key here is defining what is "useful" documentation.  Obviously, the documentation requirements must fit the task at hand; but for most business applications, even very complicated ones, I find a light and agile approach to be superior to a document driven approach.  By no means does "light and agile" mean "no process and no documentation."  The key emphasis, instead of being on documentation, is on delivering production-ready code that's clean, well-designed and well-documented.  With respect to requirements, instead of focusing on the whole kit-and-caboodle, the focus is on keeping the picture in mind while focusing on the next highest priorities that will deliver immediate value to the client.
A Simple Case Study 

To demonstrate, here's a simplified case study of my current project which I feel has been more successful than any other that I have personally led.  Specifically, it has had the fewest found bugs, has been the easiest to maintain, and has resulted in the highest client satisfaction I have experienced.  Now there are a couple of exceptions to this project which have worked in my favor...  The project was not fixed bid nor even phased bid - it was budgeted for a given year with a commitment of delivering a number of defined releases for the given year.  This budgeting approach has made the the client/provider relationship much more cooperative since the client doesn't have to worry about getting hit with change orders and the provider/developers are less pressured to deliver fragile code.  Additionally, the client understood, from his own project management experiences, that requirements change often - no matter how well they're defined - and so was more open to accepting agile techniques.  But, to make things a bit more tricky, the client in question is a state's transportation management company which has plenty of governmental oversight and auditing requirements.  An agile process was still appropriate and acceptable in this scenario.
Estimating and Project Kick-Off

To come up with an original estimate, our company and the client started with a project charter which included:  purpose, vision, driving factors to create the product, benefits of the end product, stakeholders, critical success factors, goals, scope (both in and out of scope items - very important to define what's out of scope), constraints, risks, assets, the process that will be followed (defining what type of agile techniques will be employed; defining what a release, iteration, and user stories are, etc), and commitments to communication (how requirements, changes and bugs will be tracked, etc).  The project charter was eight pages long (including the title page, TOC, and change log page) and required almost no maintenance throughout the lifetime of the project.
With the project charter as a guideline, a four-printed page Excel doc was created which defined the major releases (e.g. budget management functionality), the major themes within each release (e.g. reporting), and the anticipated high-level user stories within each theme (e.g. integrating a third party reporting tool into the product).  Finally, each user story was given a relative estimate in "points" of work, a priority (must have, want to have, and nice to have) and the associated risk.  The following is a description of the purpose of the "points" system...  (the next paragraph is taken from a book I'm working on in my spare time - i.e. when I'm not tinkering with my Lego Mindstorm NXT kit ;) 

Of particular interest in Agile Estimating and Planning is the author’s suggestion of using “points” to estimate work instead of hours or days.  With this approach, a unit of easy-to-estimate work is selected to act as a baseline for other estimates.  This baseline unit of work may be given a points-estimate of 3, for example.  Other units of work are then compared to the baseline unit of work and given estimates relative to that baseline.  For example, if the login process is expected to take 3 points of work, then the shopping cart may be expected to take 8 points of work – or almost three times the effort as the login process.  As the difference between 5 points of work and 6 points of work is unrealistically predictable, a points-scale is adhered to; an example scale is the first few above-zero numbers of the Fibonacci sequence:  1, 2, 3, 5, 8 and 13.  After the highest value / highest risk work units have been estimated, a project schedule can then be organized by determining how many points can be completed in a given iteration and then assigning units of work to the iterations, accordingly.  If the project team realizes that it’s delivering fewer or more points per iteration than originally expected, then only the points completed per iteration needs to be adjusted to fix the schedule; the tasks themselves don’t, necessarily, need to be re-estimated.  As the schedule progresses, it becomes evident how many hours of work are in one point.

With the project charter and releases-themes-user stories docs in hand, we were fully prepared to provide a relatively accurate estimate, know exactly where we needed to start (with the higher risk must-haves in the first release), and had a well-defined direction for the entire project.  This entire process took a couple weeks of effort and we were ready to begin development.  Keep in mind that this was anticipated to be a one-year project, so the initial charter/requirements phase could take just a few days for a smaller project.
Developing the Project

Once development began, we spent a couple of weeks creating "architectural spikes" for the highest risk factors in the project.  An example of this was writing a bit of code that would communicate with multiple databases concurrently.  This served two purposes.  First, it allowed us to define architectural requirements to accommodate these high risk items; therefore, we didn't have many "we have to change everything" situations which adversely affect schedule and budget.  Second, it allowed us to provide better estimates for the items we would be tackling during development.
After the high-risk architectural spikes were proven, we were able to begin iteratively defining, exploring, coding and, most importantly, delivering the product.  If at the beginning of a new release, we'd meet with the client for a couple of days to discuss goals of the release, any necessary changes to the charter/reqs doc and define highest priorities and risks.  Each release planning meeting would take about two days and occurred every couple of months.  Then at the beginning of each two-week iteration we would review what was accomplished during the last iteration, explore and document new ideas/changes/bugs that were discovered, prioritize and estimate the next iteration with a focus on items that would provide immediate business value, and get back into development.  Documentation of all of this consisted of lots of white board activity and simple user stories tracked in the very simple, and free!, requirements-tracking tool called XPlanner (  The exploring/documenting/planning phase of each iteration took about 2-16 hours.  (The initial project iterations took a couple days of planning while later iterations - after a month or two into the project - began taking only a couple hours.)  The key to all of this is that the requirements were never defined in complete detail until we were actually into the development itself.  To assist, daily 10-15 minute meetings would be held with the client (over the phone since he was offsite) to discuss progress from the day before, goals for the current day, and requirements that needed further analysis.  The following is a description of what user stories are...

A user story is a unit of work as defined by the eXtreme Programming approach to software development.  In Extreme Programming Explained, 2nd Ed., Kent Beck describes a user story as being “customer-visible functionality.  ‘Handle five times the traffic with the same response time.’ ‘Provide a two-click way for users to dial frequently used numbers.’”  Stories are given short descriptions and are defined early in the development cycle.  They’re essentially bits of functionality to be expanded upon with further discussion.  Auer and Miller, in Extreme Programming Applied, concisely defined a story as being “the simplest thing that can possibly work to make everyone in the room agree that they have a placeholder for something that needs to be done.”

Maintained Artifacts

Throughout development, the only document that was created and maintained, besides the very simply defined requirements in XPlanner, comments within the code itself, the unit tests (which are a very legitimate form of documentation) and checklists for planning meetings, was a developer's guide to the application.  This document is given to new developers and exists in the case of any buses hitting me.  The guide includes:  location of source and data repositories; locations of executables and third party tools; description of application setup and deployment with system prerequisites; how-to for deploying updates and nightly process changes; project architecture consisting of coding standards, general architectural approach, project layers and packages (data, presentation, etc.), database standards, and table descriptions; descriptions of third party components and what they provide; and integration concerns with third party applications (e.g. an external budget and scheduling tool).  After one-year of development, this document is 32 pages long, has been internally approved by the client's internal IT department, and requires about two hours of maintenance every month.  One of the key elements of this document is describing well-defined design patterns used throughout the project.
Besides the client and myself, there has been no QA department available to assist on this project.  Besides using best practice architectural techniques, the entire project has been developed using test-driven development so that a regularly executed NUnit process helps determine if new bugs have been introduced to the code.  This is a vital element to being able to hand the project off to another developer and give that developer confidence in making changes to the code.

Now there are a few caveats to this entire approach.  It assumes that most of the project is automatically tested with unit tests.  It assumes that defined design patterns have been consistently used to more easily describe the architecture and individual packages within the application.  It assumes that requirements may be changed regularly without incurring a penalty to the client besides having to drop lower priority requirements; replacing lower priority requirements with changes and new discoveries ensures that the schedule/budget will not usually be greatly affected.

Year in Review

This approach allowed us to go live with production code only a few months - on a 12-month project - after the initial, explorative meetings and regularly deploy changes and additional functionality to the end-users.  (We could still have gone live after the first month with very limited functionality.)  This approach has provided almost immediate benefits to the client's organization without having to wait for long spans of time.  This has also allowed the client to end development at any time once he feels that an appropriate level of benefit has been achieved.  Finally, at all times, the client has known exactly where development is and a sense of how successful the overall project will be when finally completed.  I'm happy to say that the 12-month project has been extended another 12-months to accommodate a completely new suite of functionality.  Perhaps I've just gotten lucky...nah ;)...I have to attribute much of it to using agile techniques, test-driven development and well established design patterns to boost maintainability.


Copyright 2007 by Billy McCafferty, All Rights Reserved

Posted 01-04-2007 11:33 AM by Billy McCafferty
Filed under:



Brian Donahue wrote re: Defining a Project Methodology, Part II
on 01-06-2007 10:32 PM

Two very well written posts, with a lot of good information.  I hope you finish up that book!  If it is similar to these posts, it sounds very interesting.

Ben Rice wrote re: Defining a Project Methodology, Part II
on 01-08-2007 5:41 PM

Explaining the use of "points" as opposed to time is one reason I wish I could force those managers/clients to read Cohn's book.  They invariably want to know "well how long will THAT take?".  I've had success in explaining "ideal hours" (most clients understand the frustration of work they know should take "2 hours" but takes 4 because of interuptions) and equating each point to 4 ideal man-hours (based on a two-week iteration).  I'm of the opinion that a task that takes fewer than 4 hours is probably too small a task and too fine a resolution to be able to estimate it again for future puurposes.  At FOCI we ran into the issue of people estimating "half-points" too.  Stay away from those.   They mess up the fibanacci sequence.  If you disagree with me and have tasks that are less than 4 ideal hours, then switch your points to 2 ideal hours or don't use my method and disregard "ideal hours" altogether.

Billy McCafferty wrote re: Defining a Project Methodology, Part II
on 01-08-2007 5:59 PM

Great points Ben.  One of the problems I've had with "ideal hours" is that even though clients say they "get it," I find that they usually really don't! ;)  The nice thing about "points" is that they remain abstract enough that a client doesn't get confused between a "normal hour" and an "ideal hour."  But, with that said, once I get into a particular user story, I estimate the tasks themselves in ideal hours, not points.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)