agile software development lab dr. günter kniesel, daniel speicher, tobias rho, pascal bihler...

Agile Software Development LabDr. Günter Kniesel, Daniel Speicher, Tobias Rho , Pascal Bihler

Spring 2008

Planning and Tracking

Sina Golesorkhi

Alexis Raptarchis

[email protected]

[email protected]

Agile Software Development Lab , Spring 2008

Prolog: Language and essential logic programming techniques 2

What is planning and why do we do it?

“Planning is the (psychological) process of thinking about the activities required to create a desired future on some scale”

We plan because we:

Need to ensure that we are always working on the most important thing we need to do.

We need to coordinate with other people.

When unexpected events occur we need to understand the consequences for the first two.



Planning in XP

The most surprising aspect of XP is it’s simple rules and practices.

They might seem awkward and naïve at first , but soon become a welcome change.

Before we can discuss the planning process in XP we need to explain some basic terms that will be used throughout this presentation.



The customer

In XP we talk allot about the customer. By customer we mean the person who makes the business decisions.

In XP the customer is not the one who pays the bill, but the one who really uses the system.

A lot of planning processes see the customer as some kind of disembodied entity outside of software development who provides requirements.

In XP the customer is part of the team and should be on hand at all times and available for questions.



User stories

A user story is a chunk of functionality that is of value to the customer. It provides a simple way for developers and customers to chop up what the system needs to do so the system can be delivered in pieces.

The best user story is a sentence or two in plain English that describes something important to the customer.

User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement.

The customer has the sole responsibility for supplying the team with user stories.



Release

The business cycle revolves around the activities of business and is at least months long:

Press releases Software releases, manufacturing and installation Training Billing

We will call one of these one- to six-month turns of the business crank a release.



Iteration

In order to be able to make midcourse corrections for a release, we must shrink the development cycle to no more then a few weeks.

We will call one of these one- to three-week development cycles an iteration.

In such a small time window it is impossible to complete anything “big”.

That is why we use the user stories as a measure of progress.



Overview:

The XP process has releases that take a few months, that divide into two-weeks iterations, that divide into tasks that take a few days. Planning allocates stories to releases and iterations in reaction to the realities of development.



Release Planning

In release planning the customer chooses a few month’s worth of stories, typically focusing on a public release.

The customer: Defines the user stories to be build in this release. Decides what business value the stories have.

The programmers: Estimate how long it will take to build each story Warn the customer about significant technical risks Provide the customer with an overall budget.

Release planning is a joint effort between the customer and the programmers.



Iteration Planning

At the beginning of each iteration the team creates an iteration plan. This plan breaks down the iteration into development tasks of a few days.

Tasks are scheduled by asking programmers to sign up for the tasks they want.

One of the most important principles in planning for Extreme Programming is that the dates are hard dates.



Iteration Planning vs. Release Planning

The release plan is synchronized to the rhythms of business. It gives the business people a way of thinking about sets of stories that together tell a good story to the market.

The iteration plan is synchronized to the rhythms of programming.

Unlike the release plan, the iteration plan is very much the developers'. They decide how to do things and in what order. But the customer is still involved.



Project Velocity

The project velocity is a measure of how much work is getting done on your project.

To measure the velocity you simply add up the estimates of the user stories that were finished during the iteration.

During the iteration planning meeting customers are allowed to choose the same number of user stories equal to the project velocity measured in the previous iteration.



Example



Tracking an Iteration

A couple of times a week the trackers needs to find out where everyone is with the iteration.

He asks the developers two questions:

1. How many ideal days have you worked on this?

2. How many more ideal days to you need before you’re done?

It’s in the programmer’s judgment whether she will be able to get in enough ideal days before the end of the iteration.



Visible Graphs

Anyone should be able to sense the state of the project by looking at a handful of graphs in the team’s working area.

Remaining Effort: Sum of the estimated time that is needed to finish the tasks.

Remaining Tasks: Number of unfinished tasks at the morning of the day.

agile software development lab dr. günter kniesel, daniel speicher, tobias rho, pascal bihler...

Documents