At Performio we work at a good and maintainable cadence. We’ve managed to get into a flow where we can basically predict outcomes for our sprints, and when things don’t go according to plan we know how to react and recover to keep our stakeholders happy. However, like most teams, it wasn’t always so smooth.
When I first joined Performio in 2018, it was a small team ready to try new ways of thinking. The basic DNA of Agile had already coalesced and I was impressed by what I had become part of. There was a sprint planning session, retrospective and an extensive (if unorganised) backlog, as things had been ticking over for some time. However, after a few sprint cycles with the team, it was clear that we were not living in an Agile paradise.
User Story grooming as a practice was largely non-existent outside of the Sprint planning session. This meant that the team were often reading a User Story for the first time as they were about to estimate the effort required to deliver it. Predictably, this resulted in poor accuracy in estimations and failure to complete sprints according to time expectations. Morale would take a hit as we fell into a common cycle:
Fail to complete cards in the estimated time
Discuss what we thought were the issues in our retrospectives
Change nothing
Repeat
Obviously, this had to stop.
One of the more common sentiments in the retrospectives of the time was that engineers found it hard to push back when they didn’t feel prepared in planning, and similarly, non-engineers didn’t feel comfortable pushing back when a finished User Story wasn’t up to the expected standard. It was very clear to me that this problem was two-fold; everyone had a different idea of what the standard was, and the burden had to be taken away from the individual and put on an agreement.
Enter the Definition of Ready and the Definition of Done.
In short, a Definition of Ready defines the standard of a User Story going into a sprint, and the Definition of Done defines the standard of the work coming out. Without these, there is no shared understanding of what it takes for quality to be a first class citizen amongst the different disciplines in the team.
Whilst the responsibility of these definitions can seem heavy, setting them in place can be quick and painless. The entire process doesn’t need to be anything more complicated than a short discussion with the team. After all, it’s just a matter of formalising expectations that you likely already have.
The Definition of Ready
A lot of Agile teams forgo a Definition of Ready, as it may be important to be more flexible for reasons ranging from the expected complexity of requirements to who actually writes the User Stories in the organisation. In Performio’s case, the domain we work in can be very complex with often very explicit requirements. For us, the Definition of Ready is essential in ensuring the quality of our product. Whilst at a high level these requirements are considered, they can sometimes be considered negotiable.
The following are some of the parts of the Performio Definition of Ready:
The most common template for the “role-feature-reason” format, most teams fall away from insisting that it be used as they grow. At Performio we still utilise it more often than not as it serves as a mental checklist for how we should be writing our User Stories. and helps us to avoid describing “what” features need to be built versus “why” they are important.
An example of this format would be:
- As a Performio Customer
I want to read about Performio’s Definition of Ready
So that I can get a deeper understanding of how the Performio product is developed
What is important to note is that this does not describe how this should be achieved, just why it is important to the described user.
Acceptance and Performance criteria describe the expected outcome of a User Story, specifically how to decide whether business value has been delivered, whether it be technical or experience based. The agreed format is a descriptive template for giving context to how a feature should behave or be presented.
An example of this format would be:
- Given I have accessed the Performio development blog
When I open the Performio Definition of Ready blog post
Then the Performio Definition of Ready blog post is rendered in my browser
One of the chief considerations for the Performio engineering team is ensuring that our product meets expectations when it comes to performance, and that we routinely attempt to improvise and optimise where possible. This effort is often characterised by Performance criteria during the execution of a User Story, and this can range from how long a page should take to load to how scalable a new calculation feature may be.
The team has an understanding of how the feature should be demonstrated
Being able to demonstrate a feature effectively is often overlooked as a requirement. Anyone who has been in a Show and Tell and has had to present the technical side of a User Story to a non-engineering team has probably felt the bite of disinterest. We make an effort to understand how we can make demonstrations engaging for our stakeholders (technical and non-technical) which is important to champion the great work we are doing for our customers.
The User Story has been estimated by the team
As a final checkpoint, a User Story that is intended to enter a Sprint must have an estimate of effort to complete. This is the agreement that the Definition of Ready has been met.
The Definition of Done
In contrast with the Definition of Ready, the Performio Definition of Done is non-negotiable. It’s a blueprint that has been built over time from activities that we have found as a team to lead to a high quality outcome. At a very high level it describes the gates we have in our development process to ensure that engineers are keeping their quality agreements, but it is also used to prescribe handover events back to stakeholders who can verify a User Story’s broader requirements have been met.
The following are some of the parts of the Performio Definition of Done:
Code has been reviewed and approved by a minimum of 2 engineers
Code reviewing at Performio is an open experience. Members of the team from all levels and disciplines are encouraged to take part. We accept that you never know what you may have missed, or when there might be a teaching moment, and it’s important for us as a team that we remain open about our work. We expect a minimum of 2 engineers to be involved in reviews as it’s an opportunity to share the load, to ensure that we have multiple perspectives represented and to generate an ongoing conversation about best practices.
Tests have been written and meet coverage requirements
We believe a good engineer has all the skills needed to test their own output. As such, we have requirements for testing coverage across functional, integration and unit tests. The key problem we solve by having this as a part of our Definition of Done is to ensure that it’s not forgotten about when there is pressure to deliver.
It seems self-evident that an engineer would strive to meet all defined Acceptance and Performance criteria, but what seemed simple when grooming and estimating effort for a User Story may have become complex by the time work has begun or completed. Acceptance and Performance criteria are how we ensure that business value has been delivered, and it’s important that we as engineers can demonstrate that to the other stakeholders.
Secondarily, by demonstrating the business value we open ourselves to conversation about the solution we have arrived at, which may lead to improvements or pivots sooner rather than later.
As a final note, it is important to reiterate that these definitions are part of having healthy conversations in our team when regarding quality. They help us be confident that we’re prepared to do the work needed and that when we’re done we’ve met stakeholder expectations. It is also important to note that neither definition is set in stone. Conway’s law dictates that software architecture will be defined by the structure of the engineering teams, and as much is true for the way in which our team defines our system of work. Our definitions change as our team changes, and I expect they will continue to do so as Performio grows.
