A lot of teams are changing to Agile. Usually they start bottom up with a development focus on getting agile. The testing is often late in the change process and testers are not that keen on this new process. This is quite logical testers don’t change that fast, they are “connected” to the requirements. So a lot of testers take the specifications and write there related tests and think there doing a great job. In a waterfall project this works out fine. But in the agile project, it is a terrible way of working. Why?
The big difference in the development process is the way specification are build. In waterfall the documentation is getting pushed down from the system design team to the development team. With agile the requested information is pulled from the product owner. (Product owner tell us what you mean with …/ can you explain this item more in stead of explaining everything you know on paper).
How can we handle this “pull” way of specification?
When realizing one product backlog item, everything that is written or drawn should help to build that feature. The development team asks for knowledge. This could be specification or even a presentation. To help in selecting there is this selection matrix or quadrants. On one side there is the buy or make choice. At the other side is, how knowledgeable is the development team in building this feature.
There is an arrow at the bottom, which says feedback. This axe shows how much is know for the development team. How much guidance the development team needs. If the subject is known than telling, specify, what the Product Owner wants in the form of acceptance criteria, preferable with written examples, is a good enough. An additional HMI sketch can be useful only if the development team needs it.
These quadrants can be read as follows: You can take every product backlog item / user story / epic and point where it is. The result is a set of default sprint backlog items.
Let’s give an example:
– A buy component. A brief description, why we need this component should be given. Probably the user story description.
– A build component that is not know enough for the development team. Then it’s wise to give a description of the user story + flow. Together with an initial HMI sketch. It is initial on purpose because there is a need for some prototyping / a couple whiteboard session or clickable prototypes to get the user story clear. This does not mean that if it’s unknown to the development team, there is more need for “detailed” specification. Interactive sessions result in more domain knowledge for the development team and probably ending up with some new requirements.
During estimation and a sprint planning session these quadrant can be useful. The whole idea behind this is to get better control / focus on what to build by eliminating the documents not used before they are created.
Was this post helpful?
More articles
fromNiels Talens
18.9.2016 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Niels Talens
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.