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 imagehelp@codebetter.com
Conveying Agile Processes Concisely to Clients

When beginning a new project of any appreciable size and scope, I always start with a project charter to define the project vision, the business case for the product, basic scope and critical success factors.  I also use the project charter to clearly define, to the stakeholders of the project, the agile processes that will be employed to manage project development.  If you've gotten to the project charter, you've surely already talked to your client about the wondrous benefits of agile development; the project charter is a great place to clarify these processes and get their buy-in.  Below is an example of the language I use to convey the agile processes and establish an agreement for management of requirements and communications.  With this in place in the project charter, the client is made plainly aware of agile methodologies and enabled to set expectations, accordingly.  You'll also find it goes a long way for instilling more confidence in them believing that you're going to successfully deliver exactly what they want.

DISCLAIMER:  I am certainly no lawyer and do not imply that what follows is legally binding or enough to keep you out of trouble on your project in any way, shape or form. ;)  If you're getting your client agreement documentation together for the first time, I would highly recommend running them by a lawyer before getting them signed by a client.  I would also recommend getting a master service agreement in place that defines all the "whereby," "thereby," and "herein" clauses that lawyers love to write!

 


Project Management Processes 

Process

To provide more immediate feedback, to better indicate progress and to aptly adjust to changing requirements, agile development techniques will be employed to deliver <project name> over a series of two-week iterative cycles.  Each successive iteration will focus on the next highest business priorities factoring in:

  • The financial value of having the features
  • The cost of developing the new features
  • The amount of impact on the rest of the project by the features
  • The amount of risk removed by developing the features

Through iterative cycles, the highest priority is to satisfy stakeholder needs through early and continuous delivery of valuable software.  Working software will be emphasized over verbose requirements documentation to measure progress and elicit feedback.  Business needs will be realized as software by organizing the project requirements as follows.

Releases

To provide more accurate estimates and to facilitate deploying features over a number of iterative cycles, project requirements will be encapsulated into a number of releases.  Each release is expected to take <release length> to complete from inception to deployment.  Requirement “themes” will encapsulate the high-level goals for each release.  It is anticipated that <project name> will be delivered over the course of <#> releases.  The following releases are listed in priority order but may be reordered based on the changing needs of project stakeholders; the bullet points are the themes within each release:

  1. <Short scope description of release 1>
    • <Description of theme 1>
    • <Description of theme 2>
  2. <Short scope description of release 2>
    • etc.

Each release will be broken down into successive two-week iterations.  Each iteration will end on a Thursday and begin on the next day, Friday.  The end-iteration Thursday will be spent reviewing progress of the previous iteration and providing feedback.  The next day, Friday, will be spent planning for the next iteration and prioritizing features.  This cycle will be repeated every two weeks.

It is anticipated that the first two-week iteration will be spent refining scope, providing more accurate estimates and developing the proof-of-concepts for higher risk items.

User Stories & Tasks

Each iteration will be broken down into a number of “user stories.”  Each user story represents a chunk of functionality that can typically be delivered in one to four days.  User stories will be the primary means of encapsulating functional requirements and for establishing a basis for estimates.  Each user story will contain:

  • User story description:  The description expresses what piece of functionality will be delivered from the user’s perspective.  An example would be “As a user, I can search for specific orders with a date range to create a custom report.”
  • Priority:  The priority of each user story is set to provide guidance for development; the highest priority user stories are typically addressed first.  The priority of a user story may be one of the following:
    • "Must have" – Necessary for the system to be viable
    • "Want to have" – Not absolutely necessary, but valuable
    • "Nice to have" – Not necessary for success of project.  It will be emphasized that at least 20% of the features defined will be declared as nice-to-haves.  This will give application stakeholders the opportunity to drop lower priority user stories in favor of higher priority changes that are discovered throughout the project without adversely affecting the schedule and budget.
  • Risk:  Each user story will be given a risk of “High,” “Medium” or “Low.”  This risk assessment will have two impacts:
    • High risk user stories that are must-haves or nice-to-haves should be split into lower risk user stories or should be given attention earlier in the project to mitigate the risk with proof-of-concepts.
    • High risk user stories that are nice-to-haves should be considered to be dropped from the project.
  • Estimate:  Each user story will be given an estimate in “points.”  The number of points a user story is given is relative to the points of other user stories.  For example, a simple user story might be given 3 points.  Another user story that is approximately twice the level of effort as the first would be given 5 points.  As iterations progress, it will become apparent how many points can be completed in a given iteration; consequently, we’ll continually have a good level of confidence for stating how long the rest of the project will take based on the number of user story points that are remaining.  (Themes represent very large user stories which are typically given point values in the range of 20-100.  When release planning begins, themes included within that release are broken down into smaller user stories usually less than or equal to 8 points each to improve estimating accuracy.)

Communications

Requirements Tracking

To better facilitate communications, and to assist with project visibility, the online tool Mingle will be utilized to track releases, themes, user stories and daily tasks.  Mingle includes a number of easy to use reporting tool and provides good real-time views of project progress.  More information concerning Mingle can be found at http://studios.thoughtworks.com/mingle-project-intelligence.

Daily Meetings

Daily meetings will be held by developers on the project.  Daily progress will then be reflected in Mingle for review by project stakeholders.  The daily meeting will be held to assess work done the previous day, make goals for the current day and to discuss any obstacles that may be impeding progress.

Iteration Review

It is imperative that project development receives regular feedback from project stakeholders.  To help facilitate this, it is recommended that <name of Product Owner> and the development team meet for face-to-face discussions to assess progress, accept change requests and provide prioritization of next requirements to be developed.  The most appropriate meeting days would be the Thursday and/or Friday representing the end of the current iteration and the beginning of the next development iteration, respectively.

 


Taking up just a couple pages in a project charter, the above clearly defines how agile methodologies will be employed during project development and sets clear expectations for the client...and they love those.  You could certainly extend this for more specific agile processes or carry it into the maintenance stages of development, but keeping it simple in the project charter is usually the most effective approach to take.  Keeping it simple also gives you more room to adjust the project management processes throughout the project life-cycle to account for lessons learned and process improvement.

Billy McCafferty


Posted 10-09-2007 1:00 PM by Billy McCafferty

[Advertisement]

Comments

DotNetKicks.com wrote Conveying Agile Processes Concisely to Clients
on 10-09-2007 4:46 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Derik Whittaker wrote re: Conveying Agile Processes Concisely to Clients
on 10-09-2007 7:44 PM

Bill,

This is a great concise overview of the agile process.  However, you did forget to mention iteration planning?  Gotta plan...

Billy McCafferty wrote re: Conveying Agile Processes Concisely to Clients
on 10-09-2007 7:52 PM

Yeah, I glazed over it pretty quickly with "It is anticipated that the first two-week iteration will be spent refining scope, providing more accurate estimates and developing the proof-of-concepts for higher risk items."  I'm not sure Mike Cohn would've thought that wise. ;)

lawyer » Conveying Agile Processes Concisely to Clients wrote lawyer &raquo; Conveying Agile Processes Concisely to Clients
on 10-10-2007 9:21 AM

Pingback from  lawyer &raquo; Conveying Agile Processes Concisely to Clients

Pete wrote re: Conveying Agile Processes Concisely to Clients
on 10-10-2007 10:27 AM

Billy-

This is good stuff. I find that I form my best practices after doing something the wrong or inefficient way about 2-3 times. In my consulting past, I attempted to write more concise requirements doc, and I found it laborious to maintain. Even worse, it made my clients impatient. I started using a charter not unlike the one you show above, and (trustworthy) clients find it much more effective and convenient. How do you write a specific detailed document about a complex project in a state of flux? Anyway, the charter above, combined with a delivery/payment plan, liabilities and contingency, and you have yourself a pretty solid contract.

Perhaps the document above could be as reusable as your NHibernateSessionManager class (I see that code in every project I look at these days)

Harry Chou wrote re: Conveying Agile Processes Concisely to Clients
on 10-10-2007 4:16 PM

Excellent!! 5 stars!!!

I wish I had read this couple months ago when I started working on my current project.

Just a minor detail - there are some places still use two-weeks (which is your preference, I guess) in stead of <release length> ...

Billy McCafferty wrote re: Conveying Agile Processes Concisely to Clients
on 10-10-2007 4:26 PM

Thanks for the feedback.  The difference between the two-week iteration length and <release length> is deliberate.  Although I recommend an iteration length of two weeks, the release length is adjustable.  Suppose you have a one year project; the release length might be 3 months to encompass sets of major themes.  On smaller projects, the release length might be 1 month, or no release tracking altogether.  Regardless of the release lenght, the iteration length is still two-weeks.

Joey Beninghove wrote re: Conveying Agile Processes Concisely to Clients
on 10-10-2007 9:48 PM

Thanks a ton Billy!  For those of us still trying to get agile practices piece-mealed into our organizations (in my case, the project-based consulting firm I work for), this kind of stuff is great!

Harry Chou wrote re: Conveying Agile Processes Concisely to Clients
on 10-11-2007 5:05 PM

Got it. Thanks.

Morten Haug wrote re: Conveying Agile Processes Concisely to Clients
on 02-28-2008 9:45 AM

Short and very good wrap-up, but errs on the side of what we as developers will bring to the table. What I really miss though, is a bit more on the client/customer side responsibilities. I find this not stressed enough in most material I read. It actually takes time from the customers to get all their priorities straight, and have ready and able people to answer questions mid-development. This is crucial to get the agile and tight feedback-loop we're all seeking.

VSquare wrote re: Conveying Agile Processes Concisely to Clients
on 04-25-2008 1:27 PM

Hi Bill,

I recently come across your article and Sample on NHibernate Best Practices with ASP.Net. This was really helpful to me as I am new to NHibernate. However, I was wondering how could you map the Orders and Products (OrderDetails) with NHibernate? Can you please throw some light on this, as I have similar requirement. Thanks.

Billy McCafferty wrote re: Conveying Agile Processes Concisely to Clients
on 04-25-2008 1:35 PM

Order should have a one-to-many relationship to OrderDetail.  OrderDetail would then have a many-to-one relationship to Product.

VSquare wrote re: Conveying Agile Processes Concisely to Clients
on 04-25-2008 3:00 PM

Thanks for your reply.

I was thinking if there is a way in which we can map order directly with products associated with the order.

Billy McCafferty wrote re: Conveying Agile Processes Concisely to Clients
on 04-25-2008 3:34 PM

I'm not sure why you'd want to, but you could do a many-to-many between Order and Product, using the OrderDetails table as the relationship holder.

VSquare wrote re: Conveying Agile Processes Concisely to Clients
on 04-26-2008 1:03 AM

Ok. But then how do I map the composite ID in Orderdetails if my OrderDetails class has the instances for Order and Product instead of OrderID values and ProductID values. Hope I am making sense.

Billy McCafferty wrote re: Conveying Agile Processes Concisely to Clients
on 04-26-2008 1:15 AM

Again, I'm not sure why you'd want to bypass creating an OrderDetail object, but you'd simply create a many-to-many within both the Product and the Order HBMs.  They'd use the OrderDetails table as the FK table holder.

VSquare wrote re: Conveying Agile Processes Concisely to Clients
on 04-26-2008 8:20 PM

Thanks Bill for the response. You are right, there is no point in bypassing OrderDetail. I will do accordingly.

VSquare wrote re: Conveying Agile Processes Concisely to Clients
on 04-27-2008 11:27 PM

Bill, I have

Class Order

{

list <OrderDetails> details;

}

class OrderDetails

{

Order order;

Product product;

}

In my page I call GetAllOrders() and want to display all the products associated with the order. I am using lazyloading.

I get the Order.OrderDetails correclty, but it is not loading the related products except the productID. Instead, it gives an exception "NHibernate.ObjectNotFoundException: No row with the given identifier exists"

What am I doing wrong?

Billy McCafferty wrote re: Conveying Agile Processes Concisely to Clients
on 04-28-2008 1:54 AM

Hi VSquare,

We'll need to look at your HBM mappings and such.  Please post your question on the NHibernate forums to get a more expedient resolution.  Thanks VSquare!

Kevin Johnston wrote re: Conveying Agile Processes Concisely to Clients
on 11-27-2008 5:02 PM

Great Charter, really concise and I hope I can get my business to adopt it!

Any comments on adopting agile when there is a lot of legacy systems to support and develop...Split your teams? Budget for legacy support? would appreciate any thoughts.

Billy McCafferty wrote re: Conveying Agile Processes Concisely to Clients
on 12-01-2008 3:57 PM

That's worry estimating using "story points" really shines.  Keeping track of story points delivered per iteration will give you a better idea of how much effort supporting legacy systems is taking up.  Consequently, the story points will self adjust to accommodate the work you're doing on legacy systems, assuming you're keeping good track of the story points committed to and completed.

Macario wrote re: Conveying Agile Processes Concisely to Clients
on 04-03-2009 4:17 PM

Hello. I hope that when I die, people say about me, 'Boy, that guy sure owed me a lot of money.'

I am from Malawi and also now teach English, tell me right I wrote the following sentence: "Lufthansa, luxair, maersk air a s, malaysia airline, malev hungarian airlines."

With respect :-(, Macario.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)