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.
Stop starting with Scrum
Don’t worry: I am not going to jump on the “agile is dead and a failure” bandwagon. I do not want you to stop working with Scrum. I just want you to stop starting with it. A lot of companies realize something’s got to change in order to survive. Especially...
18.9.2016 | 2 Minuten Lesezeit
Impact mapping and continuous validation
There is always a reason for making software. Let’s rephrase that: there should always be a reason, at least from a business perspective. How else could our products have any impact? Whether we want to make an app that that seamlessly connects riders...
- Open Source
- Agile methods
25.11.2015 | 3 Minuten Lesezeit
Continuous Validation: Meet Gareth. He is seriously unpleasant.
Hello world, please meet Gareth. He can be seriously unpleasant. Trust me, we know. But he is becoming more and more indispensable. He will tell you clearly, without emotions, when your ideas are rubbish. He will certainly not hold back and he will give...
15.9.2015 | 3 Minuten Lesezeit
After continuous integration there is continuous validation
It’s a funny thing to say that delivering business value is the most important thing when developing software. It doesn’t matter that a framework like Scrum is far from efficient, because we focus on value. We deliver business value. Working software...
- Software development
23.8.2015 | 3 Minuten Lesezeit
How assumptions are not the mother of all f-ups
The thing about trends is that they will come and they will go. So after the agile trend continuous delivery and devops are in line. I think in a way it is very nice to see that development craftsmanship practices are becoming more and more accepted....
13.7.2015 | 5 Minuten Lesezeit
DevOps, building on quicksand?
The management decides they want DevOps and Continuous Delivery. It is faster, cheaper and there are less people needed for the same work. So now DevOps and CD are set as goal for the whole company to reach in the near future. So basically engineering...
24.7.2014 | 4 Minuten Lesezeit
DevOps and Product Ownership
[This article was co-written by Miel Donkers and Niels Talens.] You could see DevOps as expanding the mindset, toolset and processes which started with Agile. Where Agile focuses on creating maximum business value as soon as possible, DevOps can help...
17.7.2014 | 7 Minuten Lesezeit
It’s all about the input
Garbage in, garbage out This is a pretty basic principle. But what do you expect? What are the odds that if you give poor descriptions of your vision and needs that the results will be as expected? 50/50? Maybe less? Within the agile community there...
7.3.2013 | 6 Minuten Lesezeit
A man went to the doctor…
“Hello Doctor, I have epicondylitis lateralis and I think we can fix that with Shockwave. Shockwave is a brand new treatment that is faster, cheaper and better than all the other methods. Everyone I know does it. Don’t bother looking that up for I’...
9.11.2012 | 2 Minuten Lesezeit
Velocity is not for you
A while ago someone told me they let their product owners participate in estimations. And I don’t mean watch how the team estimates but really estimating stories. I’ve heard about non-programming scrum master, projectmanagers, salespeople and architects...
- Agile methods
- Software development
7.10.2012 | 2 Minuten Lesezeit
RST Testing Training – James vs. Michael
I was thinking to get James Bach to the Netherlands because he has an interesting view on testing. I read a couple of the books he wrote, watched a presentation from him on video . I thought he has a lot to tell. Beginning of this year a new colleague...
22.6.2012 | 4 Minuten Lesezeit
Lean bells ringing at the hospital
Last week I was working at my house together with my father and we removed a wall to create a bigger room for the upcoming baby. While the last stone was removed he damaged his thumb quite badly. We needed to go to the hospital. As soon as we arrived...
18.6.2011 | 4 Minuten Lesezeit
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
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.
Do you still have questions? Just send me a message.