Prepare an Iteration

Define the desired outcome and feature based on the user’s expectation

Using our 4×6 User Story, Task and Defect cards, write each desired outcome/feature onto the “ID/TITLE”
section of a card. Keep each outcome as elemental as possible and do not couple outcomes together even if they
are closely related. In the “Description” portion of each card, write further details that help explain what
each desired outcome/feature is.

Prioritize each 4×6 card in terms of business priority

Prioritize each card using an ordinal scale, commonly ranging from 1-5, where higher numbers like 4 or 5
signifies high priority
work while a low number like 1 or 2 signifies less important work.

You could use a qualitative scale too, like ‘High – Medium – Low’ and even use tags that your Issue tracking
system may use, like ‘Critical’ and ‘B

Write the priority down on the card’s “Priority” area.

Back to top

Prioritize business value

Estimate complexity or difficulty

Estimate the complexity/difficulty of each task relative to others and write the number onto each card’s “Points”
area.

It helps to round estimates up or down to Fibonacci sequence

numbers (1, 2, 3, 5) to find the right grain of detail for the points values.

Back to top

Estimate Complexity in Points

Scope a organized iteration-worth of cards into the custom Backlog Holder

Prioritize the backlog

Scope an organized iteration-worth of cards into the custom Backlog Holder, Based on the Product Owner’s idea
of what needs to be done first, choose a realistic amount of cards and insert them into the Backlog Holder
(also known as scoping”). High priority cards should be at the top and lower priority cards toward the bottom.
All items scoped for an iteration should be completed during that iteration in order to maintain a healthy
Software Development Lifecycle.

Make sure the scope of work items to effort needed is reasonable. One way of determining this is by looking at a
team’s
previous “velocity”, or the number of “points” the team previously completed. If the team completed 20 points
last iteration, for example, then Points adding to 10 points would be underscoped while Points adding to 30
may be overscoped. Overscoping can lead disappointed engineers who are left thinking they aren’t capable of
doing what they are supposed to. It also means ‘handling’ overhead of the work items would still need to be
‘handled’ as they carry over from one iteration to the next.

Back to top

Execute and Observe

Let the team choose what they want to first work on

During the morning’s Daily Stand-up meeting, team members should volunteer to take cards out of the Backlog
Holder and move them into the “Stories” column of the ScrumBoard. Team members pick what they autonomously
want to do and make sure that they pick only enough to get started (i.e. one story per developer or a pair for
paired programming). One card per developer who sees it through to completion is best and makes it easy to
stay focused.

Back to top

Create 4×4 sub tasks from the 4×6 item – Define the how from the what

Create the steps that will implement/complete the 4×6 card. Think of the 4×6 cards as the “what” the 4×4 cards
as the “how.” Unlike the 4×6 cards, where the Product Owner or stakeholders define the cards, it is the
developer who chooses ownership and is responsible for defining the steps to complete the 4×6. The owner of
the 4×6 would assign Subtasks to themselves or others to help them. A graphic artist, an IT specialist, a
marketing person or content editor, for example. As the same 4×6 may require a cross cutting skill-set to
complete it, it is important to write person’s name at the Subtask level.

User story and sub-tasks columns

The owner would also transpose the
‘Points” into real time estimates here. Just as with the other 4×6’s, the smaller the item and estimate, the
more accurate the estimate will be. Try not to estimate a card that would take over two weeks, instead rework
it into multiple smaller Subtasks. As the Subtasks get defined, add them to the “Defined” column of the
ScrumBoard. If needed, overlap the cards.

Back to top

In Progress, Verified, Done

As each team member begins to work on each Subtask, they move the Subtask into the “In Progress” column. It is
important here to make sure there are not too many Subtasks in this column as it’s a sign of multitasking
which causes waste. However you may have many items in the “In Progress” column as often things happen in
concerto. When Subtasks are completed they then move into the “Verify” column so that they can be reviewed by
the Product Owner or other stakeholders.

In Progress

You can either stack the 4×4 cards in the done column until the 4×6 card they correspond to is ready to be
verified (i.e. no more of its 4×4 cards left in the defined or in progress columns and just verify the 4×6
cards), or you can verify the sub tasks before the story is complete, moving them into the done column once
they are verified.

Once a 4×6’s Subtasks are complete, the 4×6 card may move into the “Verify” column. If the 4×6 fails
verification, it goes back to the “Stories” column and new Subtasks to fix the rejected pieces are created in
the corresponding row of the “Defined” column.

Back to top

Verify

To Do: Talk about Verification, who verifies, who puts in the verification column, who takes it out,

To Do: Talk about moving items to the done column, talk about taking items out of the done column once they have
been there for a while to make room for new stories

Done

The Daily Scrum

In the Daily Standup aka the Daily Scrum the Scrum Master should use the board to see what’s being working on.
This saves time rather than asking
obvious questions like “what you did yesterday” and what will you be doing today” since it’s clearly up on the
board. You will have a chance to discuss the impediments that were impeding your progress.

Each Scrum Falcon, Hawk and Eagle have areas intended for Impediments. Rather than rehashing them again and
again you can write down the impediments in the open space provided on each ScrumBoard. Writing down the
impediments helps the problem solving since it lets them marinate until solutions are realized. 4×4 Sub tasks
or even 4×6 work items may need to be created to solve the impediment.

The Daily Standup

The Burndown Charts are updated usually when the Daily Standup is done.
It is clear to see who is doing what and how long they have been doing it since the Subtasks have time estimations
(made by the person doing the
work).

There is a problem if the time on the Subtask is grossly underestimated
and it takes longer than what it should without good reason. You will be able to see signs of lagging,
deviation and even lack of motivation based on the estimates when compared to actual progress.

Back to top

Reflect and Change

Ending Each Iteration

When the iteration is over you will have something that resembles a Burndown Chart. Good Software developers,
like good craftsmen in other professions, act like professionals by preparing, effecting, observing,
reflecting, and changing. How effective was the rate of Burndown? Was the iteration a success? What does the
iteration say about the health of the projects development?

Back to top

Demonstrable software

Software makes it in to the build! Its now a part of what gets shipped… Demonstrate this new software to the
client
It also helps interaction.

You may wish to add a Star on the card for the ones you plan to demonstrate.

Often at the end of an iteration, an iteration demo can and should be done. An iteration retrospective meeting
can be had among the team and should be done in front of the ScrumBoard to realize effective results. 4x6s
that are still on the board and still in the iteration Backog Holder ‘carry over’ to the next. Carrying over
puts you behind schedule, so it’s important to 1) scope your iteration so it can realistically be achieved 2)
get commitment from the team that it is their objective to complete all the 4x6s slated for the iteration and
to make sure there will be no further carry over. Is your team ready to act like professionals?

Back to top

Burndown Chart

Burndown Charts broadcast to everyone the total remaining points (or work) and time (in days) left in the
iteration.

The chart contains a grid of 12 rows and 16 columns, with the top of the Y-axis plotting total points and the
far right of the X-axis plotting total days.

When an iteration is estimated and scoped, add the total the points from all of the cards in the iteration and use
the value for your Burndown Chart’s Y-axis.

As days move on, the graph is updated incrementally as points are completed. The vertical gradient of the line
is determined by how many points were ‘completed’ since the last chart update. If no 4x6s were completed since
the last chart update, the line is horizontal. If there were 4x6s completed, their points are added up and the
line is drawn with a vertical gradient going down to the new ‘total remaining points left in the iteration.

The Burndown Chart

*On the X-axis, units of measurement are done in time and days and can be scaled however needed. For example a
three week (15 working days) iteration can easily be plotted as 1 day per column using 15 of the 16 columns. A
four week, 20 day iteration can be plotted as 2 days per column using 10 of the 16 columns provided. This is
just a guide and use a scale that makes sense to your iteration length.

Back to top

 
 

Leave a Reply

Your email address will not be published. Required fields are marked *