Three steps to predictable software delivery - part 1 - Preparing your work items

Rapid innovation and being first to market is something we all strive for. However, measuring the performance of a development team is anything but easy as no single measure is enough. If you only track velocity it quickly leads to decreased quality. Although your customer would like you to deliver quality work fast but at low cost, the age old truth is that from those three, you can only pick two.

Budgets are tight these days, and for any self respecting team, quality is non-negotiable. What comes to speed, working overtime is never a sustainable solution. So what is there left? A lot actually.

In this blog post I want to focus on predictability. Can your team deliver results when business needs them? Can your team keep deadlines and gain the trust of your customers by being reliable?

Predictability builds trust, and trust is what keeps your customers coming back

So what should you focus on to improve the predictability of your delivery process? I’ll boil it down to three things:

• Preparing your work items (part 1, this post)

• Empowering people (part 2)

• Ensuring the flow of work (part 3)

In order to succeed, you need to manage all three, and in this series of blog posts I’ll introduce some concepts that can help you in that journey. 
 

Preparing your work items

Work items consists of requirements, user stories, mockups - everything that the team needs to get the job done. Here are some things you should take into account when preparing your work items. 
 

Slice your work into equal sized bits

Once you have your scope defined, the next step is to slice the work into tasks that are ready to be pulled by the team members. Make sure that the tasks are small enough that they can be completed within a day or two. A typical mistake is to leave tasks too large, which makes it harder to prioritise them. Big tasks are also less likely to be completed within one sprint.
 

Write down the acceptance criteria

Acceptance criteria are the conditions that a user story must satisfy to be accepted by the Product Owner. 

Here’s an example of a user story:

As an Administrator, I want to invite new users so that I can collaborate with my team members

It's a good description but doesn't really contain enough information for team to know what exactly is expected. A set of acceptance criteria can be attached to the story to fill the gaps. 

Acceptance criteria for our example story might look like this:

• If I am an Administrator, I can see a list of users for my account

• I can invite a new user by entering the user's email address and selecting that user to be either "member" or "administrator", and clicking "send invitation"

• The user will receive an invitation email with a link to a registration form

• While the invited user hasn't completed registration, a status "pending" is shown

• When the user clicks the invitation link, a registration form is shown with the user's email address pre-filled.

• Once the invited user has completed the registration, "pending" status is removed, and the user can log in. 

When writing acceptance criteria, try to use language that is easily understood even by non-technical people. This is important especially when you have dedicated QA people or testers who are not part of the development team. Acceptance criteria should also be easily translated into one or more automated test cases.
 

Have a clear Definition Of Done

Definition of Done, or DoD, is the acceptance criteria that ensures that the tasks, once completed, are truly done, not only in terms of functionality but in terms of quality as well. Definition of Done is stated as a set of rules like

• Feature is implemented

• Unit tests are passing

• Documentation is up-to-date

• Feature is accepted by QA

• Code is in master branch

• Code is deployed to production

The Definition of Done ensures everyone on the team knows exactly what it means when something is “done”. It removes ambiguity from the question “Are you done with this feature?”. Without DoD in place, you don't know whether the developer has just done the programming part, or is the feature really ready to be released to users. We’ve all heard someone claim “but it works on my computer...”.

An explicit completion criteria can also reduce the ping-pong effect, which happens when QA has to repeatedly re-open already completed tasks due to unmet criteria. It’s always faster to complete a task at once, rather than having to revisit it several times to make fixes.

Once you’ve agreed on your DoD, have it prominently displayed in the team's working area. So that everyone can see it.
 

Estimates vs #noEstimates

Few topics have raised so much controversy among software methodologists as the question of whether teams should explicitly estimate their work or not. Estimation is the process of predicting the amount of effort required to complete a task. There's a variety of approaches to estimation, from person hours to story points to t-shirt sizes.  

The controversy stems from the fact that people are bad at making predictions in general, and especially so when it comes to making predictions in the complex world of software development. 

I'm not going to dig any deeper on this topic but there are some valid arguments for not estimating your work at all. If you’ve learned to slice your work into small items, you may find out that you don’t really need to estimate. Tasks tend to be of equal size anyway. On the other hand, If you team has found that estimating helps them plan their work, then go for it. But it's safe to say that estimates alone are not going to make your software delivery predictable, you'll need to incorporate the other techniques explained in this post (and in the followup posts) as well. 

Summary

In this blog post I covered preparations that can help your team in their journey to become good at delivering software predictably. You need to slice your work into equal sized tasks, and then make sure everyone is aware of what is required to complete a task. Including acceptance criteria to your work items will make quality assurance easier. 

But in the end it's teamwork. You need to make sure that individuals have an opportunity to give their best shot. That will be topic of my next post. Stay tuned and feel free to give your 2 cents in the comments section.