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.

Work breakdown structures are simply a way of organizing the work activities necessary to implement the project into a numbered outline form.  One of the best advantages that then comes from that is a way to provide traceability from then on throughout your project between requirements, project plans, test cases, issue logs, etc. This helps ensure nothing is lost in the cracks.  Notice I said traceability between requirements and implementation work in the WBS.  That’s an important distinction to make.  I’m a firm advocate that requirements should also be uniquely identified perhaps in a matrix or outline form, but that’s not the WBS, requirements are, well requirements, or the “what” or needs.  The WBS is an outline of the activities that the project team creates to implement those requirements.  It is the “how” or work tasks to deliver on the needs.

There are not many hard fast rules about how to construct a WBS.  Remember basic outline rules from English class in school, and use common sense and good judgment.  Generally speaking at the highest level, of the WBS outline is the object or product that your project was commissioned to produce. At the next level down could be major subcomponents, or phases of the project.  That’s where the judgment comes in.  Think of what constitutes the major chunks of work.  One of the “rules” is that one of the branches should include all the project management work, and another rule is that each branch should be complete; meaning all the subcomponents on a branch should add up to 100% of the work of the branch.  Makes sense, right?    If there is testing or integration work, that should probably be represented as well. 

So now let’s talk about traceability.  To me, this is the real advantage of using a WBS.  It makes you account for every requirement, and conversely it helps prevent scope creep by proving that every bit of work you are doing was justified by a requirement.  Let me say that again – it helps you prevent scope creep!    First, let’s discuss traceability of requirements to business objectives.  As the project scope is progressively elaborated through project charter or project definition phases through the creation of scope statements or statement of work, high level business needs, project objectives and goals will be documented.  Then, as the high level requirements are identified, it is a good idea to tag them with a unique identifier, and associate them with the project objective that they stem from.  That ensures that requirements are aligned to the objectives and business needs.  Then as the work is defined in the WBS to implement the requirements, each of those WBS elements can be tied to one or more requirement IDs.   A single requirement may be totally or partially implemented by multiple WBS elements, and/or a single WBS element may contribute to the implementation of multiple requirements.  Having a traceability matrix reveals where the connections are, which then directly assists in creating functionality test cases.  It helps ensure that no requirement has been overlooked, and that no work is the result of scope creep if it can be tied back to requirements that are themselves tied to the original business needs that justified the project business case.   Given all this incentive I’ve now hopefully instilled for creating work breakdown structures, let’s see if we can eliminate some of the reservations over difficultly.  Consider this example of a business case for a project to implement a software applicant tracking system.

Business Need:  Fill Open Positions with quality candidates in a timelier manner.

    Objective 1:  Reduce the amount of time recruiters spend reading and filtering resumes.

    Objective 2:  Reduce the amount of time recruiters spend corresponding back and forth with candidates collecting information.

    Objective 3:  Improve our ability to file and locate candidate records.

Based on the above high level need and resulting business objectives, the following high level requirements (not a complete list) may be captured and associated with the objectives.  There is obviously still a great deal of detailed requirement elaboration to be done on each one, but the high level requirements are captured below.

The high level WBS for the implementation work might look like something as follows.  (Normally, you would probably define activities to enough levels below the first level as necessary to be able to plan and manage the work):

Applicant Tracking System Implementation

1.0   Requisition Posting Module

1.1   Setup Requisition Filter options

2.0   Resume Capture

2.1   Configure Resume Storage facility

2.2   Setup Filtering Options

3.0   Build Questionnaire

4.0   Setup employment application

5.0   Testing

5.1   Test requisition

5.2   Test resume Capture

5.3   Test Questionnaire

5.4   Test employment application

6.0   Project Management

Once you have both the requirements table above and the WBS, you can then create a traceability matrix that proves you have addressed all the requirements and that you have not taken on any unnecessary work.  You should make each of the lowest items in each branch of the WBS appear in the matrix as well as each Requirement:

So if you’re one of those who have been avoiding this important and beneficial step in project planning, go ahead and give it a try on your next project.  I bet it won’t be nearly as scary as you think, and it just may keep you from forgetting something important.