4.9. Bringing it together
So how does all this fit together? First things first. To ensure good alignment of all the Elements, it is vital to know what you are aiming at (Goal). From there the question is “what has to happen, so that we can achieve this?”. The Idea is to identify the big things that need to happen (Epics). Those don’t need to be super detailed yet. To get started, it is enough to have a rough idea of the main topics. The User Story method can be helpful here, as it forces one to think about an Epic starting from the desired outcome and then goes backwards. Once you have some Epics defined it’s time to split them into Items that can be done within one Sprint. Here you can use the User Story method once again. Starting with the User Story provides a great baseline from which you can then add more and more details to your Item/Epic until it is clear what it contains.
To make sure we cover everything needed for the team to start working when defining Items, it can be useful to define when an Element is sufficiently described and therefore ready to be worked on—the Definition of Ready.
From here the only question that remains is: “when are we done?”. This is where the Definition of Done comes in. A collection of overarching quality criteria that define when an Element is considered to be done. This reflects the standards of the team.
Story
Having things ready
Our two senior members of the team, Alice and Fiona, think that it might be interesting to have a quick chat with the team. They come to see Gabriel, who is happy for the distraction. Based on what he read about Agile teams in the morning on the way to the office, he suggests moving the discussion into the secretarial office and include their secretary Oliver, who has not been involved in their discussions about new processes yet. When introducing the topic to him, they quickly find that they’ll need to visualise all work Elements, so they decide to put them on Post it notes on the whiteboard and group them as well as possible. For the moment they pin them to the board in Oliver’s office, as that’s the place they all visit often. But they feel uncomfortable with the sheer volume of Elements, especially about how to bring User Stories, the Definition of Ready, Definition of Done and Acceptance Criteria together—which goes with which?
Help comes from outside this time, as Sara confi rms a lunch appointment for next day. While this will be without Alice for the moment, Fiona and Gabriel will share their findings with her in the afternoon. Sara turns out to be very pragmatic regarding their points: she suggests starting with Items having a User Story, depending on what can be described easily, and that each Item should relate to a Definition of Ready and a Definition of Done and feature clearly spelled out Acceptance Criteria. Like this, the team is always ready to work and the person working on an Item would always be able to tell whether it’s finished or not.
Just before they part ways, Gabriel remembers that he wanted to ask Sara about teams that only spend a part of their time in an Agile team. Her answer to the question was somewhat disillusioning. One would preferably have their team members work Agile full-time but she acknowledged that this might not be feasible. It is still possible, just a little more difficult to start working in an Agile manner if you also have to work non-Agile at the same time. This can still work, if there is a core team that has most of its time dedicated to it.
Example
Item 5: Set up a table to align the arguments before court with the submission/argument, relevant proof, the legal basis, and potential applications to the court.
User Story:
As an attorney, I want to have all arguments and relevant details easy at hand, so that when I go to court and discuss a particular argument, I don’t have to look for the most important information.
Tasks:
Acceptance Criteria:
Definition of Ready:
Definition of Done:
Last updated