Agile Planning - Goals, benefits and details

Owned by Daphne Ogle
Last updated: May 20, 2009Version comment

Agile development is a software design and development methodology that advocates having many, short iterations throughout the life-cycle of the project. Fluid's agile planning process uses 2-week iterations, where all the work is planned at the beginning of the iteration. At the end of the iteration, how much work was actually completed is compared to what was planned (velocity), and this information helps determine how much work to plan for the next iteration.

Goals

Transparent status
both within the design team and across the community

Encourage & enable frequent conversation
about status of work, priority, roadblocks, what we are learning, what has changed, etc.

Reflect on what we know & priorities
through the "planning game" that kicks off each iteration

Focus during iterations
new requests, needs, changes, etc. become part of the next iterations "planning game" to allow us to stay out of reactionary mode

Make mistakes faster
we learn from mistakes so the sooner we know about them the sooner we can build our depth of knowledge and correct where needed

Create a comfortable place to share ideas
no idea is a bad one; we want people to feel comfortable sharing design ideas with early and often and know they can expect to get the right level of feedback.

The Plan

Communication

Interactive Planning Status

to kick off each iteration, the team gets together to:

  • write and estimate new design tasks
  • re-estimate tasks not completed in previous iteration
  • prioritize tasks for current iteration
  • assign tasks to designers

Design team stand-up meetings

Meant to be short & simple meeting. This meeting happens everyday (or at consistent intervals) at the same time. In a shared environment, everyone stands to remind people the meeting is short we can decide if this makes sense for us. Each participant has a chance to answer to 3 questions as we go around the room. The questions are:

  1. What have you done since the last stand-up?
  2. What do you plan to do before the next stand-up?
  3. What impediments are in your way?

Any other questions are typically handled outside the stand-up in follow-up conversations as-needed.

Open communication

via phone, IM, breeze, email between team members

Show and Tell Presentations

  • at the end of an iteration, team members have an opportunity to share current work with the rest of the team to get feedback, share status, etc. 
  • design work will be presented to the community - how often or is this loose?  over confluence & email?

Stability in the midst of change

Planning & Sharing

Story cards drive our work and are the plan

  • tasks are represented on story cards (need to figure out how to do this digitally) and assigned to a high level project.
  • each story card gets a time estimate by the team. Estimates can be no longer than an iteration.  If they are, they should be broken down into smaller chunks of work.
  • during the planning game, story cards can easily be moved around in order to play "what if" games and talk about trade-offs. So, if a new story card needs to come into the iteration than something that was already planned must go. This forms the plan for the iteration and beyond.
  • story cards are assigned to a designer or a set of designers whatever is appropriate based on the amount of Fluid design time they have for an iteration. If a designer is working 100% on Fluid, 80% of their time could be assigned to story cards for instance (that 20% is for administrivia, email, and fires that just can't wait).
  • the current iteration's plan is pretty set in stone, the next iteration is pretty well understood except for surprises that come up during the prior iteration.  As we move out into time, the plan is less and less concrete yet there is still a plan.

The status board

we will maintain a "status board" to demonstrate work progress to ourselves and the community. The board includes:

  • Tasks assigned for the iteration
  • Who is assigned the task
  • What tasks have been started
  • What tasks have been completed
  • What tasks are blocked

How do we do this in the digital world? My experience has been with index cards hanging on the wall and colored dots to show status.

Additional

  • from http://www.implementingscrum.com/cartoons/implementingscrum-20060911.html
    A Pig is someone who has skin in the game. Mike Cohn aptly refers to the people in that role as, "Having their Bacon on the line." Pig roles are considered core team members. Performers. People who "do" work.
    A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to "getting things done." Their "eggs" are a renewable resource, and many get laid.

    • At the daily stand-up, only pigs can talk. Chickens can come to the meeting to observe and learn, but they cannot:
      • talk
      • make funny faces
      • whisper
      • take notes loudly
      • communicate in any way

Resources About Agile UI Design

On this Page