─ Online Poker estimating tool: (Free from Mountain Goat Software: www.planningpoker.com ) when teams are performing relative story point estimates and they are all in the same room, they frequently use poker cards. After discussing the story, each team member chooses the card with the number of points they believe the effort represents and all members hold up their card at the same time, so that no one is effected by anyone else’s vote. When someone is not in the room, this requires a different tool. There is an online version of the physical cards where members select their number and only when all members “playing the game” have made a choice, does the moderator release the selections so that everyone can see the numbers chosen.
─ Livemeeting, Gotomeeting, Webex, or other conferencing tools: tools allowing virtual meeting and presentation of materials or system demoing, remote desktop sharing, etc.
─ Skype, other teleconferencing tools: to allow virtual “face to face” interaction
─ Instant messaging: to allow texting/chatting between team members. There should be team covenants regarding responsiveness to IM, email, phone calls, and other forms of virtual contact in the absence of physical contact.
─ Sharepoint, Google Docs, Basecamp, other collaboration platforms: a strong collaboration platform is needed for storage of notes and design documentation. Team calendars, ground rules, conventions and protocols, time zone information, burn down charts, product backlogs, and other team artifacts can be stored here.

While some thought needs to be given to how to divide work and include remote teams or remote participants of a team, many organizations are successfully utilizing agile methods on virtual teams. As with any project any time, the key is in developing creative and consistent ways to communicate among the separated team members.

Processes:   The primary scrum processes allow for grooming of the product backlog or clarifying the complexity by specifying effort factor (story points), grouping work from the product backlog into work iterations, defining and estimating technical work tasks for the work iterations, and packaging completed outputs of the work iterations into a working release product.  Below is a breakdown of the different scrum processes along with their descriptions and analogous waterfall counterpart.

Meetings:    Since frequent feedback is the hallmark of agile, the scrum meeting are the settings that facilitate some of the above processes, as well as allow for frequent status during the work intervals or sprints, and provide the vehicle for the customer acceptance and process improvement.  Below is a table that describes the major scrum meetings, descriptions and their waterfall counterparts.

 Artifacts:  Artifacts are sparse compared to a typical waterfall methodology. All work “to do” is tracked on the product backlog.  Work “left to go”  is tracked on one of 2 types of burn down charts and are meant to show progress to the organization.  Business requirements will seem sketchy in agile as compared to waterfall since preference is given to conversations amongst members of the team, and verification through acceptance criteria and demonstrations.  Below is a description of scrum artifacts.

 In scrum, relative estimation keeps the estimation process intuitive and non specific.  It’s done in group session with the entire team where everyone “votes” on their number all at once to keep voting independent.  The relative story points assist the product manager in backlog prioritization.  Sprint planning makes up the rest of the planning for a 30 day period.  This is where the detailed task decomposition and hourly estimation occurs.

Once a sprint is planned, work is executed and monitored in the daily standup meetings.  Issues are tracked in the Sprint impediment log.  Progress is displayed to the organization in artifacts such as the sprint and product burn down charts.

At the end of the sprint, the work is verified and accepted or rejected in the sprint demonstration meeting.  Then the sprint processes are reviewed and suggestions for improvement are made in the sprint retrospective, before reprioritizing the product backlog if necessary and beginning a new sprint.

I first became interested in agile when I was leading technology teams and consistently struggled with the standard waterfall challenge of getting accurate, complete, well understand and well documented business requirements for long software development application projects.  Once we felt like we finally got things “nailed down” and began design and development work, requirements would change before we could deliver the first release.  The agile methodology is a natural solution for this.  I began my own course of self study, networking and training, and eventually acquired a scrum master certification.

To understand the principles of any of the flavors of agile methodology (and there are several), you need to first understand the agile manifesto, developed by the original set of agile founders:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scrum happens to be one of the most popular types of agile and derives its name from a daily standup meeting called the scrum meeting, involving the team and the facilitator who is called the scrum master.  Below is a discussion which breaks down some of the important roles used in scrum and compares them to their analogous counterpart in a waterfall methodology. 

Roles – there are only 3 officially recognized roles on an agile scrum team:

• Product Owner – The product owner is a member of the scrum team and is responsible for what the team builds and for optimizing the value of it.  He/she owns decisions and risks regarding what business stakeholders want.  He/she defines the features to be produced and decides on release date and content, and determines feature priorities.  He/she can change features and priority between sprints.  He/she negotiates acceptance criteria for work results with rest of team
• Scrum Master – facilitates process and keeps things moving.  He/she manages the internal dynamics of the team including the relationship of the product owner with the rest of the team.  He/she enforces the scrum framework.  He/she ensures full team involvement in all meetings and keeps everything visible, including “radiating” information to the larger organization.  He/she shields the team from external interference.  He/she advocates improved practices.  Very important:  He/she facilitates, but does not manage.  The scrum master has no official authority over the team.  He/she cannot assign work to the team.
• Team – This is a small (7 +-2 member) cross functional group who are responsible for the work they agree to take on during the work period called a sprint.  They are a self organizing unit – meaning they assign sprint work tasks to themselves.  They negotiate the work of the sprint with the product owner.  Along with the product owner, they demo the work results to the stakeholders.

The product owner is analogous to a business analyst, product manager or sponsor in a waterfall methodology, and the team is similar to any team anywhere, with the exception of the self organizing part.  That’s a little loose-y goose-y for a lot of management teams to get used to.  Frankly, what I’ve seen in a lot of companies I’ve networked with is a gradual approach to this, because as much as this sounds like a great goal, in companies that have been highly command and control, teams have to get as used to it as the managers themselves do.  The scrum master could be similar to a technical team lead or a technical project manager in some organizations.  What is strikingly missing in this model is the overall project manager him/herself.  The traditional, all controlling, project manager doesn’t really have a direct correlation.  To find a home in an agile practicing organization the PMI style project manager has to make some decisions.  For individuals with a more product oriented, business slant, the product owner might be a great role to assume.  For the more technically minded, the scrum master role might be a better fit.

One of the most intriguing differences between agile and waterfall and what in my mind makes agile so compelling is in the area of scope control.  In the waterfall methodology we go to great lengths to define the scope of the project in as much detail as we can all up front, and then protect that scope.  We define a rigid scope change process which acts as a deterrent to anyone who wants to introduce changes to the work that we already have a complex tangle of design plans around, because of the cost and pain of implementation when you work on everything all at once.  With agile the notion of scope control is virtually non-existent, except within the context of the short periods of work, called sprints.  This is by design.  This is to allow and even encourage the product owner to be flexible and change their mind in between sprints as the business sees the results of work and reacts to it; and as events in the business change. 

In a nutshell, product features and all other work are maintained in a document called the product backlog, in single threaded priority by the product owner.  The team determines “chunks” of that work off the top that they can perform in time boxed periods of work called sprints (usually 30 days).  Once a sprint starts, the scrum master insures that the scope of the sprint does not change.  At the end of the sprint the team and the product owner jointly demo the work that has been completed to the business stakeholders.  The product backlog is reprioritized if necessary by the product owner and another sprint is started.  Sprints are repeated until enough work is completed to comprise a release.  Sounds simple huh?  Well there’s a little more to it than that.

In my next article I will discuss the small set of artifacts, meetings and processes involved and discuss what they compare to in a waterfall context.

According to Dictionary.com, a template is “anything that determines or serves as a pattern; a model”.  The idea of a Requirements Template is to provide your organization with a thorough and far-reaching list of questions or areas of inquiry to either answer or rule out at the beginning of every project.  If you include input from enough people and groups, whether they typically identified as project stakeholders or not, you can eliminate many of the scope problems that your organization’s projects might have encountered in the past. 

If you ever do projects for external customers, start your template-building exercise with Marketing and Business Development.  Ask them about what types of features customer and prospects initially express interest in and what marketing and advertising messages they respond to.  This can give you some good high-level areas of inquiry for your Template by helping you understand what prompts your external customers to engage with your organization. 

Next, visit with the Sales group and ask them to think about every problem customers have identified as wanting to solve when they accept a sales proposal.  Ask them also to think about customer satisfaction issues after a sale is completed:  what characterized projects that had satisfied customers, and what characterized projects that didn’t.  Ask them to describe situations where the customer was temporarily unhappy and why.  Ask to see any type of documentation they use to begin identifying what a customer wants. Then start building your list of questions. 

If you are dealing only with internal customers, start by reviewing the documents that accompany any request for a new project.  You want to include all of this information, but your template will go into much greater detail.  Interview someone from your organization’s Steering Committee and ask them what is missing from the current initiation documents they use.  Ask for examples of specific projects that got kicked back from the Steering Committee due to insufficient information, and get them to identify the types of additional information needed for them to make a ruling on a new project.  Continue building your Template by adding this to your list of questions.

Next, visit with all the teams that are responsible for executing the project plan.  Talk to developers, DBAs, cost estimators, trainers, folks who do the documentation; basically, everyone who actually performs work on a project in your organization.  Ask them for a list of everything they end up needing to know in the middle of the project that no one ever asked at the beginning.  Ask them what kind of work they are doing in the stabilization period, and if that work is a result of missed requirements.  Ask them for the most common examples, as well as the outliers.  Your goal is to create a comprehensive list of everything that should be considered at the beginning of a project.

Then move on to your support teams – whoever is responsible for the product of the project once it is operational.  Ask them to identify the things they wish someone on the project team was asking about.  Again, ask for the odd and unusual situations as well as the most common examples.

Finally, spend a little time with other groups that may not be at all involved in the project, but can potentially be affected problems with a project, like Legal, Accounting, Corporate Compliance and Public Relations.  Ask if they have ever been affected by missed project requirements, or have an area of potential concern around project requirements.  Document their concerns as areas of inquiry to consider during the requirements phase.

If you have all these conversations and hear all these war stories, you will be able to create a useful tool for the people in your organization who have the responsibility of collecting requirements.  Continue to updated and modify your Requirements Template as new information becomes available. 

In addition to getting your project off to a good start and nipping some scope creep issues in the bud, you may find that this tool helps you have better conversations with customers, both internal and external, by helping them uncover needs they didn’t know they had or gaps in their process they hadn’t discovered yet.

Good luck!

In constructing your complexity model you are essentially identifying the factors that complicate the various types of work your organization does.  This can be a great teambuilding exercise for developers that can bring clarity and structure to the estimation process. 

1. To get started, you want to assemble a cross functional team of experts from your development organization. 
2. Capture the different work types for your environment.  These can be driven by environmental factors such as specific technologies (e.g. SAP, Oracle, Microsoft) or specific architectures (e.g.  ERP, e-commerce, n-tiered, distributed).    Types might be development of things such as database elements (stored procedures, triggers, tables, indexes, etc.), a .NET or Java user interface window, a report, or some other special component as defined by specific technology / architecture present in the environment.
3. For each work type, document the types of things that contribute to complexity of development.  For example, in the case of database stored procedures, some of the elements that add to complexity might be:

• Call parameters
• Table references
• Table field references
• Intermediate values set
• Referential Integrity checks (for triggers)
• Components Called
• Trigger cascades
• Branch logic (if/then/else)
• Embedded looping
• Data derivation complexity
• Calculation complexity
• Error handling
• Performance criteria

 4. Parse each of the above list elements into 3 levels to comprise low, medium, and high complexity as outlined below:

5. Finally, assign a development estimate in hours for each of the above complexity levels based on group consensus from past experience.  Capture these as initial values to plug in for estimates, and make adjustments as new data becomes available from actual projects.

In planning for new projects, the complexity model numbers can be used as a basis for estimates delivered.  Once the actual work is completed, during lessons learned review sessions, it is important to compare the actuals to the values in the complexity model and to re-calibrate the model for the next time.  This allows for continuous improvement and accuracy of the model over time.

Planning estimates are generally considered to have an accuracy of 10 to 25% from actual.  This is because more information is known at this point than at the project selection or request point, but not as much as when all requirements have been finally required and refined.  Now obviously this is dependent on my subjective definitions of “high level scope statement” vs. “detailed scope statement”.  Scope should be outlined enough to describe feature sets or groups or deliverables and their basic functionality.  Once this is available, a working group of key representatives from each major component of the technical implementation team should be assembled to formulate the planning estimate. For example, web developers, database administrators, server developers, report developers, and any other specialty discipline required for the solution.  The scope elements detailed in the high level statement should be listed and grouped together by feature set.  For each element or combination of scope elements, the technical team identifies the technical work components required to deliver the solution in abstract.  By abstract, I mean high level, non – actionable work units.  For example, let’s say the high level scope statement contains language outlining the need for a web application and screen interfaces that facilitate employee registration for training classes.  The high level or abstract work units might be a set of database definition tables to define employee information, as well as a set of tables to define the training class information, as well as user interfaces to allow maintenance of schedules by administrators, and attendance requests by employees.  When the actual database elements get designed, they will no doubt manifest into a family of related tables with proper referential integrity for the employee information, and another similar family of tables for the training class information.  But at this point in the process, the team simply identifies a unit of work of database definition for each of the major hubs of data tables involved.  Similarly, there is a unit of work identified for a UI for standard screen maintenance of class information, and a UI for employee registration.  The fine details of what exactly are on each screen are not considered or detailed at this point.  The team uses a combination of analogous estimating and expert judgment to consider the work that resulted on past projects.

Now what creates consistency is to develop a scale, where for every type of work, and for a range of complexity levels, you record pre-set metrics (which are validated and calibrated over time).  These values can then be plugged in to your estimate, once the team determines the complexity level of the current effort under consideration.  So as an example, let’s say in your development environment you have determined that user interfaces of low complexity take 40 man hours to develop; medium complexity take 60  hours to develop; and high complexity take 80 hours to develop.  “Complexity” is subject to your own definition and should be documented with the applicable factors in a complexity model.  As your team recognizes that a medium complexity interface will be necessary for the employee training project, you would plug in 60 hours for that unit of work. 

All of these high level units of technical work are grouped together with the scope feature sets they are required by.  Along with each one, the team records the man hour estimate (according to the complexity model), as well as resource type required to perform it – i.e. database administrator or web developer or report developer, etc.  What this allows you to do is aggregate man hours by feature set, or by resource type – depending on how you need to deliver estimate information. 

If you have limited resources (and who doesn’t?), you can even give a crude sense of the calendar time required as you level the hours with the number of resources you think you will actually have available to deploy on the project.  This is not schedule development, mind you, but what I would call “macro scheduling”.  You are definitely not issuing a completion date because that is dependent on the start date which is usually dependant on many other things that are not certain at this point.  The detailed schedule also requires detailed tasks or activities and their dependencies which are also not yet developed until the WBS is completed.  But by taking the total number of man hours for each resource type, and dividing by the number of estimated work resources of that type available; you can determine the approximate elapsed “calendar” time for that activity type.  Then by sequencing any natural dependencies, such as database design work preceding development, then adding up the longest path, you can determine a rough estimate of calendar time for your work effort. 

So, let’s see what all this looks like in our employee training project example: 

Feature Set:  Screen interfaces that facilitate employee registration for training classes

• Abstract Work Unit: Employee information definition tables
• Complexity:  Medium
• Man hours: 40
• Resource Type:   DBA

• Abstract Work Unit: Training Class information definition tables
• Complexity:  Medium
• Man hours: 40
• Resource Type:   DBA

• Abstract Work Unit: Training Class Maintenance User Interface
• Complexity:  Medium
• Man hours: 60
• Resource Type:   Web Developer

• Abstract Work Unit: Employee Maintenance User Interface
• Complexity:  Medium
• Man hours: 60
• Resource Type:   Web Developer

• Abstract Work Unit: Training Class Registration User Interface
• Complexity:  Low
• Man hours: 40
• Resource Type:   Web Developer

Total:  80 DBA hours; 160 Web Developer hours = total 240 man hours.  You can give a blended rate cost or if your different resource types have different hourly rates, you can give a more accurate resource cost since you have the hours broken out by resource type.

If we have 1 DBA and 2 web developers available; since all the database design work must generally be done before much development can be done, in a crude sense with thumb in the air we can say that the job can be done in roughly (80 hrs / 1DBA) + (160 hrs / 2 web developers) = 2 weeks + 2 weeks or 1 month. 

Involving the technical team in an exercise such as this early in the process helps create a high sense of legitimacy to a planning estimate.  By tying the abstract work units to their associated scope feature sets, you set the stage for traceability on the project, without imposing an unduly burdensome exercise.  In addition this level of documentation adds substance and credibility to the estimates quoted and referencing the metrics from past projects adds merit as you communicate to sponsors.  Probably the best benefit however, is that it is an early teambuilding activity and facilitates buy in of the schedule and project plan by the team.

There is no silver bullet answer to this.  You cannot get a high quality detailed estimate without detailed requirements.  One simple approach to this however, is to not try to over think things at the project selection stage.  It is an established fact that estimates have a greater degree of risk and less certainty earlier in the project when less is known.  Rough order of magnitude (ROM) estimates made during project initiation can have margins of error in the range of +-50% from actual.  As the project progresses and knowledge increases, the risk goes down and the margin of error on the estimate decreases to as little as -5 to +10% when all the requirements are hammered out.  So beating the team up to get a binding estimate at the beginning is futile and the selection committee should be educated on that.  A technique that works better is using range buckets.   The ‘McDonald’s approach’: i.e.  - small-medium-large works very well for this.  Usually a project request has been documented briefly with some amount of information regarding high level purpose and objective, business need and justification.  Based on this, a technical resource should be able to slot the project into one of 3 possible ranges or buckets such as:

The actual numbers associated with small, medium, and large, can of course be adjusted to whatever makes sense in your organization.  This first estimate should be understood to be within some amount of error, depending on the detail in the project request, but enough to determine approval.

We like to re-visit estimates twice more during the project.  After the scope baseline has been defined, a second estimate, considered a “planning estimate” is developed.  This should generally be between 10 – 25% from actual. The third time is after detailed requirements are developed and clarified between the business and the implementation team.  That is when the team should achieve the -5 to +10%  accuracy.  The rule is, at each of these points if the new estimate varies significantly from the understanding of the project steering (approval) committee, the team must seek permission to continue, or make adjustments to scope to get back to the cost in the original estimate.  That way the team is protected from being saddled with work they didn’t get funding for in the original estimate, and the sponsors stay in control of costs.