4squareviews

I’m going through the Agile Practice Guide on a systematic basis to review all of its contents.   Chapter 5 covers the implementation of a project in an agile environment.

Section 5.2 of this chapter covers the eight most common agile project practices, which are:

5.2.1 Retrospectives

5.2.2 Backlog preparation

5.2.3 Backlog refinement

5.2.4 Daily Standups

5.2.5 Demonstrations/Reviews

5.2.6 Planning for Iteration-Based Agile

5.2.7 Execution Practices that Help Teams Deliver Value

5.2.8 Iterations and Increments Help Deliver Working Product

I covered the first five items in previous posts.   The sixth item is what I’m covering today.    There are two ways of managing the work flow on an agile project:

• Flow-based:  an iteration is considered complete when the team reaches some sort of milestone, like when it completes a major deliverable, ships something or even completes a release.   It is based on the completion of a definable chunk of work.
• Iteration-based:  an iteration is done on a regular basis, with a two-week iteration being the most popular.

The common agile practices related to planning for iteration-based agile (the second option above) are what is being covered today.

First of all, the team must establish the length of the iteration, with two weeks and four weeks being the most popular options.   Note that it is possible for a new team to meet once a week at the beginning when the team is getting used to working together, and then lengthening the iteration to two weeks once there is a rapport established between team members.

Second, the group needs to decide what story size the team has the capacity to handle within a given iteration.

Third, the product owner has to take into account when people are unavailable, as they will not be working at full capacity or perhaps even at all (for example, when they are in vacation).   When teams have a reduced capacity, the team needs to plan for work that meets that capacity.

Fourth, it is best for the product owner to make the stories smaller in the beginning so that the teams see progress in the form of a finished product, and therefore gain confidence to be able to take on more work during an iteration.

The big takeaway from agile planning vs. traditional project management planning, is that in agile, you do not plan just one in a single chunk, but a little at a time.   Once the work is delivered, the retrospectives described in an earlier post keep the team on track, so that they can plan a little more of the work for the next cycle.

So this deals with managing the scope, a measure of the completeness of the work.   The correctness of the work is also vital, and that takes you into the domain of quality.

The next post will cover the execution practices that help teams deliver value.

Filed under: Uncategorized |