Over the years that I have been coaching Agile teams, these are a few of the areas that I have seen that teams and their stakeholders can improve on.
Think in iterations
The basic principles of Agile are to break down a project into bite-sized chunks to focus on deliverable sized iterations and yet this, even in its approach, is often misunderstood or not even considered.
One of the biggest differences of Agile compared to traditional Waterfall projects is to aim for an initial Minimum Viable Product (MVP) and then continue to build on that until you’re happy to release, as opposed to building the whole thing at once and hoping it works at the end of the project. This, of course, allows you to adapt and change as you go, and this is what people are not used to.
The key is to think small and then iterate but I often see people struggle to adapt to this approach and they just keep trying to build and build until they reach the end. This is like building a tunnel and never checking to see if you’re still heading in the right direction and just hoping for the best.
A lot of times this comes down to two things.
Firstly, ensure you know and agree with what your MVP looks like. What is the core functionality of the thing you’re building and what must it do to be considered a thing. Stakeholders are going to argue about the bells and whistles but just remind them that we’re not talking about a public release, we’re talking about having something internally that we can start to play with, a prototype.
Ongoing, this is also about simply using the right language when you’re talking about the scope of the project. Rather than using phrases like “out of scope” or “drop from scope”, instead talk about the up coming versions.
“We can’t fit this in now but we can schedule it for the next version.”
Always wanting to be better
If your team is dreading a retrospective, then they are a team that has lost their desire to be better or they are afraid to speak up for fear of being ridiculed, seen to be doubting management.
This is very much a cultural matter, a team that is confident in evaluating themselves has the best chance of evolving.
Evaluate how you are doing your retros, where you are doing them and when. Try to make them at a time that has less impact on people as well as making it as fun as possible, so they feel comfortable talking about what’s bothering them.
The team should be viewing the evolution of their processes in the same way that they evolve their work and resulting product.
Biting off more then you can chew
This is really an occurrence that happens in all projects, where the desire of what we want is greater than our ability to deliver it and there is nothing wrong with being ambitious.
However, when it comes to planning, it’s better to be as realistic as possible and ensure that your sprint planning works within your teams’ velocity.
“Stretching” to a higher velocity almost never results in the higher velocity, instead it just results in an unfinished sprint and more work carrying over to the following sprint, which can very quickly become a bad habit. Even if the team worked all weekend and late nights, the potential increase in velocity is minimal and the consideration has to be whether this will result in an extra deliverable. There are times when it can and the extra push over the finish line is achievable but be realistic about it.
If you are repeatedly carrying work over into the next sprint, re-estimate your items for the remaining work in the new sprint. The ‘lost’ points will adjust the velocity accordingly and it will also act as a bit of an incentive to get things through to Done.
Unfinished tasks are also a sign that the items are too big and need to be broken down into smaller sizes.
Achievable goals carry far more optimism then unrealistic ones.
Breaking down items as a team
The breakdown of epics into stories and tasks is one of the single most important steps of an Agile project but it is not the sole responsibility of the Product Owner, it is something that the team must do together, both product and technical.
The story can be broken down in a number of ways, such as individual users journies or each of the steps a user takes through a journey but ultimately they need to be broken down in iterative steps and in a manner that allows stories to be prioritised and worked on separately.
A conversation between the Product Owner and the technical leads will determine the best method for breaking down an epic into deliverable pieces, not one or the other alone.
This process is not only important for planning but begins the conversation on the solution and the boundaries of technical possibilities and will often result in a breakdown to an MVP of the feature then later versions delivering the iteration of that feature.
Iteration of features, not just the product
Teams can make the mistake of thinking that a feature is an iteration, where if approached properly, each feature will have an MVP and further iterations.
This will allow your whole product to grow and evolve at a controllable pace.
As you approach each new epic, as mentioned in the breakdown above, try to break the feature down in a method that can be separated and priorotised part by part.
Consider what is your MVP for a feature.
Stories that everyone understands
Like a good short film, a story does not need to be long, to be good.
The single purpose of the story is to define the intention as well as the purpose and function of a piece of work. If the people delivering the work understand the intention and the boundaries to work within, then the story has served its purpose and has the best chance of delivering the work intended.
There are best practices that are worth considering such as user story and acceptance criteria structures but ultimately the minimum information required for a story to be ready for a sprint is a decision that the team must agree on together.
The team must decide on the structure of a story
Understanding the difference between a story and a task
One of the big advantages of a Scrum team is that the work is measurable and with multiple sprints, you can then predict your path, both within the sprint and into the future of the project.
A story is the intended outcome and a task is a workload to deliver that story.
Within a sprint, if you’re incorporating QA for your stories, then separating out your workload into tasks is a nice way to be able to measure the work that is complete vs the deliverable being ready.
Although the deliverable being ready is a part of the definition of done, the main purpose of the burndown chart is to determine if you’re on track or not. You want to know how close you are to being Done. If your points are all stocked up in the story and the work is in QA, then burndown still hasn’t shifted which is not indicating that you’ve already completed a large chunk of the work.
If you have points on your technical tasks, your team can mark them as done once the work has been completed, which will show in your burndown chart while some small points should still remain on your story to cover the effort required for the team to complete testing and get the task through QA.
Remember that the QA team is a part of the same delivery, so points must be included for them to get the item through to Done.
Recognising the timing to scaling
If you’re a large team or a team that is in the process of scaling up, then it is important to always be evaluating your structure and determining if it is time to change that structure.
Most teams will start in a default platform or departmental structure and this will work while the team is small but as you scale up, you need to be able to evaluate whether you should change that structure to a team focused on deliverable components instead.
Now, this isn’t saying that you have to go cross-functional because you’ve scaled up, it’s most likely that cross-functional will be beneficial but that’s not always a certainty.
The key is that you stop and evaluate your team structure often to ensure it is the best fit for your projects and if it’s not, don’t be afraid to try a different structure. Give it enough time to settle in but if it doesn’t work, change it back. As long as you’re giving your teams the flexibility to evolve the way they work and you have measurability in the output, then you are allowing them to process.
In other words, try something, if the velocity drops, try something else.
Don’t forget testing
Of course, you’ll be doing QA testing during the sprint…you are doing QA testing in the sprint, aren’t you?!
When it comes time for release, make sure you have tickets to leave a gap for resolving issues that will come out of Release Candidate testing. If you’re doing a programme plan via sprint allocation, using something like Jira Portfolio, for example, you’ll need to have a point boxed ticket a make sure that testing is being considered.
Capturing all effort
This one is pretty obvious but it’s still one that teams can struggle with and it really comes down to protecting the sprint.
The easiest way to handle this is making sure you have a process if priorities change and the team, as a whole, agree to break the sprint to react to a changing situation.
I recommend having the following three options to offer to the team if a change is presented;
- If the estimate remains as it was, that is, it won’t take extra time, accept the change, update the story to reflect it and continue on.
- If the estimate is different, particularly if it’s greater, accept the change, update the story criteria and points. Calculate the difference in points and remove a lower priority item from the sprint of the same value. For example, if the ticket was a two and now it’s a five, remove tickets totalling three points.
- If the estimate is different, more work and but you don’t want to break the sprint, continue with the story as it is and then add a new story for the change to be picked up in a later sprint.
Having a process to handle these requests makes it easier to “Yep, sure, these are our options” rather than just saying no. Have the data to be able to imedidately report the impact.
Focus on the backlog
The scrum team will already be doing this of course so this one is really for the broader team and educating the Agile methods upwards. Always talk about the backlog, where things are sitting in the backlog, their relationship to other items, how they are prioritised, which release they are scheduled for etc.
Constantly referring to the backlog is the best way to educate stakeholders on how Agile works since they’ll be able to relate to it with their own requirements. When stakeholders or management want to discuss priorities, use the backlog.
Review your DOD and DOR
Make sure you have a realistic and simple “Definition of Ready” and “Definition of Done”. Try not to make them too complicated because then people won’t be bothered to follow them, same goes for achievable. If the requirements are not being met then revisit your definitions and change them so they work.
Remember that both these definitions need to be agreed to by all parties in the team so that everyone is on the same page.
Agree on how the team will work together
A phrase repeated a lot in the above topics was that the team would agree on an approach together.
A very important part of any project, particularly when you’re kicking off a new one, is to stop, discuss and agree on how the team will work together. What approach are you going to take, Scrum or Kanban, what is more important to the team, the delivery date or the scope?
These are all questions that are often assumed rather than discussed. Remember that most people will arrive at a project with their own ideas and methods they have used in the past and might assume that everyone else is used to doing things they way they are used to doing things, and with so many variations of Agile out there, you can’t make those assumptions.