Peter’s session resulted in 6 pages of notes, which I won’t go into in masses of detail (yet).
Suffice to say there was a massive amount of technique rammed into 1 hour starting with Intent Driven Design as a mechanism for requirements gathering. The basis of this technique is the derivation of Business Intent (the Why of a project) which can determine the driver behind development.
Generally speaking, one should avoid projects that introduce more than 5 Intent items as a greater number would denote the need for breaking down a project into further phases or units.
The next concept introduced was that of Audiences (the Who of a project) which is fairly easy to understand. These audiences or roles are the functional groups in a project, the user types, the interested parties.
Drilling down into the project Peter explained the use of User Stories to identify specific requirements. Effectively User Stories can identify areas of Shared Need within a project.
As User Stories are well known and well documented online I’ll skip the next couple of pages of notes highlighting only that Peter recommends the batching of 0 point tasks into a single story with a value for use in estimating.
The use of Stories and IDD in terms of production of estimates and trackable units was of great interest to me as was Peter’s focus on the functionality side of a project. The basic concept of build something you can use to fulfil the requirements and worry about making it look good or work more easily sounds commonsensical but is so often over looked!
The only downside to Peter’s otherwise brilliant preso was the assumption (or hope?) that we all live in a world where we can afford to say to our clients “Pay me to estimate” all too often good estimating techniques fall by the wayside due to pitch / profit issues.
Anyway back to the session, Peter introduced the concept of planning Poker (a bit gimmicky?) and the more useful (for me anyway) Magic Estimating technique which I will definitely be introducing at our larger project kick offs.
The tongue in cheek mention of APIs (muted groans from around the room) as the feature that always takes at least twice as long to build as expected was part of Peter’s section on feature types which, whilst a little cynical was pretty much bang on for 99% of the features in any project I’ve ever worked on.
A final wrap up of the Iron triangle and the introduction of buffers and the first session of the day came to a whirlwind stop.
Scores (out of 10)
Direct Professional Value: 8
Ongoing General Value: 9
Contention / Debate: 5
Style: 10
Overall: 8
