Archive

Archive for the ‘Agile Scrum’ Category

When Done is Done in Agile Scrum

May 16th, 2009

rightwritten by gunther gerlach-2009

In management process, there are few needs to happen for the sprint (iteration) to be called done. There are at least three types of Definitions of done.

 

Story Definition of done

·      A Story definition of done would look like this.

·      All stories should have automated acceptance test.

·      The story should have working code supported by unit test that provide around 60 – 70 percent coverage.

·      The story should have well defined acceptance criteria.

Gunther Gerlach

What is a Pair Programming?

May 16th, 2009

peoplewritten by gunther gerlach-2009

An XP practice where two programmers work alongside each other, trying to get a task accomplished. Two minds at one problem!

 

How this help?

 

·         It brings up productivity if the pair knows what it is up to. A chatty pair can cause more damage to the project than getting done

·         It keeps each person honest. If you don’t know something its apparent in the fifth minute.

·         It helps keep the quality of the code. Since the pair is helping code.

·         This is where design happens.

Gunther Gerlach

What Story Points are?

May 16th, 2009

z-estiwritten by gunther gerlach-2009

are used to measure the effort required to implement a story and is measure based on Size, Factorial, Squares or Fibonacci techniques. This is a random measure used by Scrum teams.

This is mainly done as we as humans and as managers are better at abstract terms. If we use hours as a way to size stories, then the managers in the room have questions, teams don’t immediately feel comfortable with hours…

Duration

Size

Factorial

Squares

Fibonacci

1 – 3 day

X Small

   1  (1!)

 1 – 12

1

Gunther Gerlach

Understanding Your Project Velocity

April 28th, 2009

velocitywritten by gunther gerlach-2009

is terminology from the  methodology and is basically the same concept as in more traditional methods.

 

How it works: Select a regular time period over which to measure . If you’re using fixed or iterations, use that time period. Otherwise you can use weeks, fortnights or months. It doesn’t really matter which as long as you’re consistent. Add up the estimates for all the tasks/deliverables/features in your chosen time period. It doesn’t matter whether the estimates are in days, hours or even in relative . Only include the estimates for any items that are 100% complete and signed off within the time period. Anything still in progress counts as zero, as there is no value in incomplete work.

Gunther Gerlach

Agile Scrum Project Status Reporting

April 28th, 2009

sharewritten by gunther gerlach-2009

Obviously the daily stand-up (or daily scrum) is a good form of . It’s great for people with a close interest in the project who can spare the time to get to the scrum. But it’s really no good for other that can’t get to the scrum each day, either because they are interested in less detail, or because they have an interest in many projects and can’t be at all the scrums.

Gunther Gerlach

Create the Product Backlog

April 28th, 2009

createwritten by gunther gerlach-2009

 

The , in its simplest form, is a list of things that people want to be done to the product, in priority order. Anyone can add anything to the . Anyone. The process, and agile development principles generally, are collaborative and inclusive. There is no longer any need to say no.

Only the can prioritize the .

 

The can contain anything. Anything relating to the product that is. Bugs. Enhancements. Whole projects. Issues. Risks. Anything. Having said that, items on the should ideally be expressed in business terms that are of some value to the user (or customer, or business). Not as technical tasks.

Gunther Gerlach