This is a "just enough, just in time" concept.
Please read these blog posts:
http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html
http://scrum.jeffsutherland.com/2008/09/agile-spefiction-is-it-hoaz-or.html
OK. So, it is something 'written' that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need. To get it done right. Quickly. High quality. Etc.
What might it contain?
Well, anything useful.
I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.
It is simplest to think of the Agile Spec being 'written' 'one sprint ahead'. And being checked for 'ready, ready' before the Sprint Planning Meeting. But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.
Maybe hand-written, maybe on a wiki. Maybe in a Word doc.
Who writes it? Well, the best people, of course (self-organize!).
It might hold:
It does not repeat the usual BS that we used to put in specs. That no one really read.
It does not say all the stuff they know well already. It is not trying to be 'comprehensive'.
We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.
We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.
And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).
For some people, who maybe had too much fun in college, we need to write or draw more.
For some people, who maybe took their Ginkgo today, we need to write or draw less.
Any questions?
Please read these blog posts:
http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html
http://scrum.jeffsutherland.com/2008/09/agile-spefiction-is-it-hoaz-or.html
OK. So, it is something 'written' that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need. To get it done right. Quickly. High quality. Etc.
What might it contain?
Well, anything useful.
I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.
It is simplest to think of the Agile Spec being 'written' 'one sprint ahead'. And being checked for 'ready, ready' before the Sprint Planning Meeting. But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.
Maybe hand-written, maybe on a wiki. Maybe in a Word doc.
Who writes it? Well, the best people, of course (self-organize!).
It might hold:
- the acceptance criteria
- a business flow
- a list of business rules
- a wire frame(s)
- a mock-up of the screen (if that means something different to you)
- a simple use case kind of flow (not all the darn UML use case stuff... just something, just enough) (to me, this is a variation on a business flow, using a few specific symbols)
- a data flow
- new data elements (or whatever you guys call them)
- key data elements and key values in this context
- a screen flow
- a simple design picture
- a data flow, maybe simplified
- an example (eg, if X, Y, Z inputs, then we expect A, B, C outputs)
- anything else they may find useful to build it quickly and for it to EXCITE the customer
It does not repeat the usual BS that we used to put in specs. That no one really read.
It does not say all the stuff they know well already. It is not trying to be 'comprehensive'.
We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.
We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.
And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).
For some people, who maybe had too much fun in college, we need to write or draw more.
For some people, who maybe took their Ginkgo today, we need to write or draw less.
Any questions?
No comments:
Post a Comment