Ouija Board Estimation

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Agile Tools vs. Agile Books: The value of tools over the value of books in the agile world

By Paul Heidema

I have been working with Agile for a couple of years. At Berteig Consulting we are using Agile to run our small business. As such we try to use various tools to make our life easier. We have used CardMeeting for our cycles and tasks. I have tried using PlanningPoker for online estimation. It seems useful, but maybe our team is too small to make great use of it. I am also looking for other ways to manage the reflections and learning from each cycle.

I have received an email from David Wolrich of CardMeeting that states: “Anyways, I rely on the trickle of news from legitimate organizations like yours to let users know that CardMeeting is still around, that I am still adding features, and to generate interest; thanks again.” So maybe some of you could try it and give him a shout. Much like other free applications on the net such as Drupal and Neo Office this one could become more robust and useful.

Continue reading this article.

Ouija Board Estimation: A fun technique for agile estimating

By Paul Goddard

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Effective Retrospectives & Reviews: A CSP’s perspective on continuously improving both the process and the product.

By Marco Mulder

Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review and a retrospective at the end of each sprint, too many teams fail to implement the improvements they identify. In my experience, there are two common causes for this:

• Teams don’t have or maintain explicit standards for their product and process;

• Teams don't use the product backlog to schedule improvements.

Set a Dynamic Standard

A definition of done in Scrum defines general acceptance criteria to which all implemented features should adhere. This ensures that everyone has the same understanding of what it means for a feature to be “done.” Team members must all know these general acceptance criteria so that they know when they’re finished. The product owner and stakeholders need a definition of done so that they know what they can expect from the features delivered by the team. That does not mean, however, that the initial definition of done is the one you will want to use throughout the project's lifecycle. In fact, one of the reasons why an explicit definition of done is important is that it not only says what will be included in each feature, it also makes explicit what is not included. Some of the things not included may be planned additions later in the project.

Continue reading this article.

Keep Your Team Seeing RED

By Nimesh Soni

True project success can be summed up in one acronym: RED (requirements gathering, estimation, and delivery). Each of these key activities is crucial to a successful project launch.

Requirements Gathering

In Scrum, we write user stories to capture a project’s ever changing requirements. Because project needs fluctuate, Scrum doesn’t consider requirements gathering to be a one-time task. Instead, Scrum focuses on the incremental unfolding of requirements. The work is decomposed and captured at different levels in varying levels of detail during the project. At each level, the work is broken down into smaller, more manageable pieces of work.

Product backlog (PB): High-level capabilities and features are captured as user stories. The PB is the repository of all the work that needs to happen during the project.

Sprint backlog: The team identifies the user stories that will be worked on during the current iteration, or sprint. Each user story is decomposed further into tasks.

User stories should be validation-centric. The team needs to identify and write down the validation conditions for each user story. The story should not be closed until these validation conditions are met satisfactorily. As Ron Jeffries mentions, user stories have three critical components (the 3 C's of User Stories): cards (physical medium), conversation (discussion surrounding stories), and confirmation (tests and validation that verify story completion). 

Keeping the INVEST acronym in sight can also help agile teams write better stories. A user story should be:

Independent:
A good story should stand on its own.

Negotiable:
A good story is negotiable. It is not an explicit contract for features; rather, details are co-created by the customer and programmer during development. A good story captures the essence, not the details.

Valuable:
A user story should be valuable to the business.

Estimable:
The team should be able to gauge the size of a story.

Small:
A good rule of thumb is that a user story should not be more than eight to sixteen hours of effort. 

Testable:
The story should include validation criteria.

When writing individual, detailed tasks under each user story, teams should focus on writing SMARTtasks.

Specific
Measurable
Achievable
Relevant
Time-boxed

Estimation

Once the requirements are captured as user stories in the product backlog, the business will want to know how long it will take to develop the product and when it will be delivered. Estimation is done in two stages: at the individual user story level and at the sprint level (velocity).
The team assigns story points to each user story. These points are an indication of how long each story will take. One story point might be eight developer hours or two developer hours, depending on the team’s estimation scale. One way to calculate these point estimates is by using planning poker. User story-level estimates are usually done at sprint zero (release planning); they also might be done during sprint planning for each iteration.

Accurate estimates can be achieved through:

• A better understanding of user stories. A better understanding allows team to write clear user stories with "just enough" detail to enable the team to have a conversation with the business (customer) at a later date. Having the dedicated and active involvement of the business will help the team to understand and write better stories.
• Clear identification of validation for each user story. The validation should be written before estimation. Having validation clearly defined with the user story will make it very clear to the team what effort is involved for the story and when the story can be closed.
• Active involvement of the business. Having the business involved at all stages (sprint zero/release planning, planning for each sprint, and sprint review) will enable the team to have proper priorities for each sprint. The business will also be there to clarify any user stories that might confuse the team.
• Cross-functional teams. As Mike Cohn mentions, "planning poker brings together multiple expert opinions to do the estimating. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else" (Agile Estimating and Planning by Mike Cohn). Having a cross-functional team enables the team to provide more accurate estimates.
• Planning poker: Using planning poker with a cross-functional team will ensure that you get accurate estimates.
• Clear definition of done: Clearly defining what must be completed before the team can say a user story is “done” helps the team provide accurate estimates.

The second level of estimation, sprint level estimation, is a “progressively elaborated” technique. As the team moves from one work sprint to another and closes various stories, it soon can determine its velocity: a measure of how many story points the team is able to close within a sprint. Based on the estimates and known velocity of the team, it is possible to forecast different dates within the release plan and predict how many sprints will be required to complete the project. Feature-level burnup charts can also help teams track their progress at the release level and provide more accurate answers as to when the product will be delivered.

Delivery

One promise of agile is "potentially shippable product increment" (Mike Cohn) at the end of each iteration/sprint. During each iteration, the Scrum Master (SM) should ensure that the work the team committed to do during that sprint is what the team actually delivers.

• The SM should ensure that the team understands the user stories and provides accurate estimates. 
• Once the team commits to a unit of work (and is in a sprint), the SM should make sure that the team is focused only on the user stories that are within the current sprint.
• During the sprint, the SM should also ensure that the team is focused on the sprint work (and only the sprint work). He/she should eliminate any impediments that might be blocking the team’s progress.
• The SM should maintain the task burndown chart and story burnup charts, along with the team’s velocity calculations.

Along with these tasks, I also used the spikes in the sprint burndown charts to gauge the quality of the estimates. We also added a dashboard report that was posted on the sprint wiki page and updated regularly. This one-page dashboard report lists the goals of the sprint, and the status of each in terms of red, yellow, and green, where green signifies on track/completed and red symbolizes off-track. This dashboard report also lists any known impediments/issues and status on each of them (open or closed).

By continually focusing your team on RED (requirements, estimation, delivery), you’ll be better able to keep your project in the green.  

The RED Grid

	Requirements	Estimation	Delivery
Tools & Techniques	User story cards	Planning Poker Story Points	Velocity  Feature burnup chart
Key Roles	Business (Business stories) Team (technical, enabling stories)	Team along with the business/product owner	Team
Key Concepts / Guidelines	Write in the format "As a <role> I want to <action> to deliver <business value>. INVEST 3 C's of user stories Validation centric	Write validation first (before estimating) Define DONE Create a cross- functional team with active, dedicated business involvement	Each work sprint should produce potentially shippable, working product Refactoring

Problems You Could Face While Planning Sprints Using Planning Poker

Planning Poker is a process used for estimation during the Sprint planning meeting, many times with actual cards rather than software. The various team members do their estimation of the tasks using Fibonacci numbering sequence, and after a couple of rounds of discussion, a finalization of the estimates are done, and these are converted into Sprint Backlog. However, for teams that are not very comfortable with Planning Poker, there can be several problems as dealing with Planning Poker. Some of these are:

• For somebody who is not comfortable dealing with Planning Poker, the concept of providing estimates in this manner can be confusing to people. Guidance, simulation and some hand-holding during early stages is essential
• There can be ego clashes if the estimates provided by team members vary widely, with the senior team members not being very comfortable if the estimates provided by the more junior ones are accepted. This needs careful handling
• Once numbers are presented in the meeting, then non-team members (including the product owner and senior stakeholders) will accept these numbers, and any further refinements start getting compared against these numbers
• Once somebody sees a number by somebody else, they start getting doubts over their numbers and if given a chance, many of the team members are willing to modify their numbers (just by doing some modifications in their head over the estimation). This can sometimes lead to a quick firming of the estimates towards a more accurate number, but can also lead to a herd mentality behavior
• Planning Poker is hard to do when the team is distributed, and needs more careful planning in terms of logistical coordination
• In Planning Poker, the assumption is that the team member has the required level of knowledge, but this can be inaccurate, what can happen in many cases is that the team has as much knowledge as is available, but there are many blank areas that are not yet filled, whether these be requirements from the product owner, or dependencies that are not known
• In some cases, the Product Owner is not satisfied by the varying estimates, and may want to put pressure to select the lower estimate so as to get more features in the current Sprint. The ScrumMaster needs to be pretty vigilant to avoid these scenarios