Planning Game in Artifacts Tracker (AT) Project

Michal Pilawski

Agenda

• Introduction to Planning Game

• Planning Game in Reality of AT Project

• Implementation

• Summary

General Terms

• Agile Development - A generic term meaning to do development in an iterative, incremental fashion, using the code produced as a measure of success, rather than artifact generation.

• Agile is a project whose practices are designed around the expectation that things will change as the project moves forward:– requirements – developer knowledge– project practices etc.

• These projects still require planning. However, the planning cannot be completed up front, the plan must evolve as the project proceeds.

Source: Net Objectives, 2002

Introduction to Planning Game

The Goal of the game is to maximize the value of software produced by the team. From the value of the software, you have to deduct the cost of its development, and the risk incurred during development.

The Strategy for the team is to invest as little as possible to put the most valuable functionality into production as quickly as possible, but only in conjunction with the programming and design strategies designed to reduce the risk.

The Pieces in the planning game are the story cards.

The Players in the planning game are Development (AT project team) and Business (Petteri and Heikki)

Source: Beck (2000)

Planning Game Explained

What valuable features can be implemented in a given period of time?• In XP the planning perspective is quite short: just one release (if possible a release

takes „no more than two months” (Jeffries et al., 2001)). Iterations take usually no more than three weeks.

– Rapid feedback

– Simpler planning

1. Planning game is used at the beginning of each release and iteration.

2. The customer brings a set of user stories.

3. The development team:• Estimates the effort required to implement each story

• Assesses the technical risks associated with each story

• Specifies how many hours they will be able to spend on the project in a given release or iteration.

4. The customer decides which functionalities should be implemented in a given release (iteration) on a basis of effort estimates and benefits the functionality would bring to the customer.

Flow of Planning Game

Source: Net Objectives, 2002

User Stories

• System is described through the user stories that explain its basic functionalities:

System helps tracking effort used for doing each of the task. Time spent on the task as well as estimates of effort needed to close the task are available all the time. This data is inputed to the system by its users.

• User Stories are stored on story cards that contain following information:– Date and story number– Software engineer name and effort estimate– Task Description– Software engineer notes– Task Tracking (Date, Status, To Do, Comments)

• All user stories and their implementation tracking on the AT project website

Responsibilities

• Customer:– Timing and scope of each release of the product– Scope of the product features– Prioritize features

• Project team:– Effort estimates for each feature– Consequences of technical alternatives– Development process and practices

Modified Planning Game

XP assumes that there is only one customer representative for the project (or many representatives speak the same voice).

• AT project has two customers (Petteri Sulonen, Heikki Vesalainen)

• Petteri Sulonen is the Senior Customer (he signs the invoices ;) )– Final decission if contradictory requirements

– No time to discuss some details of the system

• No need for Delphi method (only two customers)• Some user stories written by H. Vesalainen• Who is responsible for prioritization for each iteration?• If H. Vesalainen is not able to buy a valuable story (all his stories

are too expensive), he returns his „budget” for each iteration to the senior customer.

Based on Nawrocki et al. (2002)

Summary

• Quick feedback.

• More user friendly (easier to meet customer satisfaction)

• Perfect for small teams, active customer and agile development

• Very effective when requirements and project understanding evolve/change with the project progress.

References

1. Beck K.: Extreme Programming Explained: Embrace Change. Addison-Wesley, Boston, 2000.

2. Beck K., Fowler M.: Planning extreme programming. Addison-Wesley, Boston, 2001.

3. Jeffries R., Anderson A., Hendrickson C.: Extreme Programming Installed. Addison-Wesley, Boston, 2001.

4. Nawrocki J., Jasiński M., Walter B., Wojciechowski A.: Extreme Programming Modified: Embrace Requirements Engineering Practices. Proceedings of the IEEE Joint International Conference on Requirements Engineering

5. Net Objectives (www.netobjectives.com)

6. Scott W.: Extreme Programming: Turning the world upside down. IEE Computing & Control Engineering, June – July 2003.

Thank you very much

Any questions?