4 Advantages of Physical Task Boards

For new teams I try and encourage them to use a physical task board over tracking tasks in a tool. This can be problematic when all team members are not in the same location, but it has some huge advantages for co-located teams.

Structure of our Task Board:

• 5 Columns: Planned, In Progress, Verify, Hours Remaining, Complete
• Each Committed story for the iteration is given a swimlane/ row
• All Development tasks are on white cards
• All Testing tasks are on green cards
• All defects are on hot pink cards
• Orange sticker dots were used for tasks that are blocked
• Story cards are 4x6, task cards are 3x5
• We have used whiteboards with tape or cork board with push pins
• Daily Standups are done in front of the board, we encourage team members to point at the card during their 3 questions, move cards, burndown hours. Each team member should be signing up for their daily commitment and putting those cards in progress.
• Hours burndown is updated for each story at end of standup
• Burndown chart and any other metrics are placed on and around the board - radiate information
• Should be visible to all team members (i.e. that way when a QA person sees a developer move a task they know to ask if it is ready for testing)

Advantages of Task Boards:

• Promotes team interaction and discussion - Throughout the day you will see teammates, stakeholders and members of other teams stop by the board for discussion. This increases greatly if the board is located near the team and highly visible
• Visibility - Anyone walking buy can make a quick second assessment on where the team is in the iteration. No cards left for a row? That story is complete. No white cards left, just green cards? Only testing remains. Lots of pink cards? Lots of defects.
• Good for new teams to visualize Scrum - By having this tangible thing in front of them that they can touch, makes it easier for new Scrum teams to understand the process
• Support full team commitment - Now the whole team sees all of the tasks daily and keeps them from just focusing on "their" tasks. When using task tracking tools it is too easy to just create a view of "my tasks" and then tune out the rest.
  

Agile Estimation Workshop

Here are the Agile Estimation Workshop slides that I used for the for the Agile Austin Workshop this weekend.

http://docs.google.com/present/view?id=dgswtwn6_54cw3dpwrt



For further knowledge I would recommend Mike Cohn's book on the subject:

5 Reasons Why Estimating in Story Points is a Superior Method

I get a little resistance from teams to start using Story Points for estimating, but it really is a superior way to estimate over hour based estimates.

Story Points should be used to estimate User Stories and quickly provide estimates to the Product Owner so that they can prioritize the product backlog. I recommend using the Planning Poker technique to get everyone on the team involved and timebox the estimating process.

What are Story Points?

Story Points are a relative measure of complexity, i.e. How big a feature is compared to other features. This type of estimating removes the notion of time from the estimate as team productivity is measured separately as Velocity.

Advantages:

• Quicker to Estimate
• Keeps Things Relative - Two team members can agree quicker that one feature is twice as complex as another compared to agreeing on how long it will take to implement. A senior developer may argue that it takes 2 days while it will take 4 days for a junior developer.
• Stay out of the Weeds - If the team has to think about every little thing to build a bottoms up hours estimate then they will tend to try and understand every requirement detail and think through the design to much. When estimating in points you only have to think about comparative complexity, as opposed to trying to think about everything required to implement the feature.
• Do Not Get Stale - As team productivity changes there is no need to re-estimate. Velocity will change but the comparative complexity will still be valid.
• Better Metrics - Since scope is isolated from productivity I can now report on how the scope is changing. If I had my estimate in hours it is difficult to determine if the change was from a scope or productivity change. For a release I like to report two main things to my stakeholders: scope (total points recorded at each sprint) and work completed/ velocity. This gives me clear visibility to both scope and velocity compared to the plan.
• Inaccurate Estimates get Resolved - If up front the team made overly optimistic or pessimistic estimates we will gain quick visibility to this as the team records Velocity in the first couple iterations.We will then be able to adjust the plan accordingly without having to re-estimate.

Articles of Reference:
The Case for Story Points - Peteon Rails
How Do Story Points Relate to Hours? - Mike Cohn
Agile Estimating Presentation - Mike Cohn

Suceeding with Agile

I am reading Mike Cohn's new Book. So far it has the potential to be one of the top books that I would refer to folks.

Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit

I am still trying to figure out where Kanban fits in this Agile world. Some part of me thinks it is for people that can't be disciplined enough to do Scrum well, but I can see some use for some support and sustaining development teams whose priorities may change very often due to business needs. I stumbled on this article as a decent primer to Kanban.

Kanban development oversimplified: a simple explanation of how
Kanban adds to the ever-growing Agile toolkit

Agile Estimating Workshop

I am facilitating an Agile Estimating Workshop on Sat. Feb 27th. If you are interested sign up here:
http://agileestimating.eventbrite.com/

Tidbits from Mike Cohn CSM Class

Here are some tidbits I took away from Mike Cohn's CSM class:

• It is ok to have a sprint at the end of the iteration called "hardening" or "release" sprint. Don't call it a "stabilization" sprint as then this may encourage the team to be lax and leave testing and defect fixing tasks to the end that should be finishing in the iteration. This sprint should be used to do final integration, performance/ stress testing, user acceptance, etc. The key principal is that the duration of the release sprint must be independent of the number of the preceding sprints. If it isn't then those tasks should have been done in the real sprints.
  
• A team should dedicate 10% of their time prepping for the next sprint. Reviewing the backlog, working with the PO to breakdown stories, etc. Anything to ensure the team will be ready to do sprint planning for the next highest priority stories in the backlog. This may be designated folks or all members of the team.
• Clarifications are ok during a sprint, changes are not
• You should never have an "analysis" or "testing" sprint. That is not Agile, that is waterfall. Stop kidding yourself.
• Teams are self-organizing, not self-managing. Management still needs to define the goal so they can work within the boundary of a problem.
• Mike prefers to end Sprints on Thursdays as this promotes less weekend overtime. In the last week of the iteration the team would have Monday-Thurs to get everything wrapped up as opposed to Fri-Mon.
• The sprint goal is most useful to communicate to external stakeholders what the team is accomplishing.
• The primary goal of Sprint Planning is for the team to feel comfortable committing to the designated backlog items.
• When doing planning poker use the question, "How big is this?" As opposed to, "How long will this take?
• When bootstrapping a team with points have the team pick out a 2 point story and a 5 point story and then use those as the relative scale for further estimating.
• A typical team should be able to estimate 15-20 items an hour. 3-4 minutes per item.
• On a burndown chart don't call it the ideal line call it the hypothetical line
  
• Parkinson's Law - Work expands to fill the time available
• The Product Owner is a Pig. They are accountable for success therefore that makes them an integral part of the team.
• Use the term "other stuff" for team members to report in the daily scrum. It avoids them going into details about items outside the scope of team, but alerts the ScrumMaster so that he can determine if it is becoming an impediment.
• The primary purpose of the Sprint Review is to gather feedback