As part of a recent Iteration zero I facilitated a chartering session.

A chartering session helps a team understand the parameters of its work and its context within the project, preparing them to make well-informed decisions going forward. To begin understanding the project, the team identifies any assumptions and constraints and maps out the project community, highlighting the key stakeholders. By identifying the value the project will deliver to the business, the team can develop trust and confidence that the project is needed. Creating a charter provides an opportunity for the team to begin demonstrating self-organisation by articulating a shared project vision, defining their criteria for success (try using Remember the Future , an innovation game from Enthiosys , to include the customer's definitions of success relating to the business value to be delivered by the project), and agreeing the working practices to be used.

I can't share most of the charter information because of client-confidentiality, but I can outline the agreed working practices adopted by the team.

WORKING PRACTICES

The working practices the team were to use in the project were agreed by consensus .


workingpractices
Originally uploaded by sjb140470 .
Planning and Estimation

1. The development team will estimate stories in Ideal Pair Days (the uninterrupted elapsed time that excludes meetings/sickness/days-off and does not include buffering). It is understood by the whole team that Ideal Pair Days are not equivalent to Man-Days. Estimates for stories include time for functional testing to be completed within the iteration.

2. The whole team will collaborate to evolve stories as they approach being planned into the next iteration. Over time, stories will be progressively split into smaller stories with a narrower functional focus. The stories planned into the next iteration will take between 1 and 2 Ideal Pair Days to complete.

3. The development team will use just-in-time tasking to manage the work to complete a story.

4. For a story to be considered done (complete, ready for deployment to production and therefore counted in the team's velocity), the code should compile, have a simple design with the fewest classes, be well factored, have no duplication, be clean, structured to the Sun Java coding conventions , be self-documenting, communicate the programmer's intentions, be checked into the version control repository, be integrated and build successfully. All the unit tests should pass with a code coverage >85%. All the acceptance tests should pass. The story's implementation should be checked by a UI designer, the test team and the customer. It is understood by the whole team that this should be accomplished within an iteration.

Tracking Progress

1. The development team's progress in terms of expended effort and remaining effort will be tracked on a big visible burndown chart .

2. The number of running tested stories will be tracked on a big visible chart .

Test-Driven Development

1. The development team will write automated acceptance tests before writing implementation code. FIT will be used to directly test the business logic. Selenium will be used to test the UI (and the business logic indirectly).

2. The development team will write JUnit tests before writing Java implementation code.

3. The development team will write JSUnit tests before writing Javascript implementation code.

4. When a defect is located, the development team will write JUnit (and JSUnit ) tests to reproduce the defect before fixing it.

Continuous Integration

1. The development team will integrate working code often, no longer than every 2 hours.

2. The development team will not tolerate broken builds. If the build is broken the team should refocus to fix the build immediately.

3. The development team will not check-in new code if the automated build is broken.

Coding

1. Developers will write all production code using pair programming.

2. Developers will write all production code to the Sun Java coding conventions .

3. The whole team owns all of the code.

4. The development team will use the code and tests as the primary source of any documentation to be produced.

Iterative and Incremental Development

1. The development team will deploy a new release of production-quality software to the DEMO/UAT environment every 4 weeks.

2. The development team will work to a weekly iteration cycle starting on a Wednesday and concluding on the following Tuesday. The completed stories will be deployed to the DEV environment at the end of the iteration.