Share on FacebookTweet about this on TwitterShare on LinkedIn

Room to Breathe: 7 Steps to Better Burndown & Velocity

Share on FacebookTweet about this on TwitterShare on LinkedIn

Have you ever been part of an agile project where no matter how much you try to align the team, you experience these problems?

    • Frequent scope changes
    • Work is not prepared enough for an iteration and work has to be added mid-iteration to keep the team productive
    • Burndown seems to be stagnant or inconsistent from one iteration to the next
    • Low throughput
    • Product owners and the development team are constantly under pressure to get more work done which may require overtime
    • Inconsistent velocity and poor predictability on project progress
    • Planning feels like a chore and meetings feel like a waste of time

If any of this seems familiar to you, you’re not alone. Even the most seasoned agile professionals struggle sometimes as each project and team is unique and presents its own set of challenges.

Being agile means embracing change and looking for ways to continuously improve. As a project leader you can employ techniques to overcome these common challenges and make life easier for the team.

Case Study

We’ll use a real life example to show how these tips can work on an actual project.

Imagine leading a software project where your company has been contracted to build an enterprise e-commerce system to power your client’s new website. Our task manager of choice is Atlassian JIRA, but of course this is one tool of many.

The 14 person team consists of:

    • 1 Executive Stakeholder who funds the project and reports back to the C-suite
    • 1 Product Owner who sets the priority of the backlog
    • 3 Functional Managers who inform requirements
    • 1 Project Leader
    • 1 Business Analyst who works with stakeholders to write and organize the epics and user stories
    • 1 Software Architect
    • 2 Software Engineers
    • 1 Front End Developer
    • 2 Quality Assurance Engineers
    • 1 User Acceptance Tester

In the last 3 iterations, the performance looks like this:

 

 

Iteration 35 — Quick Additions & Removal Early Iteration, Low Throughput

 

 

 

 

 

Iteration 36 Additions Mid-Iteration, Successful Burndown, Low Throughput

 

 

 

 

 

 

Iteration 37 — Late Iteration Additions, Low Burndown, Low Throughput

After analyzing the last three iterations, the culprits have been identified:

  • Quickly shifting backlog priorities
  • Stories added during the iteration
  • Stories not sufficiently prepared for development

1. Taming the Backlog

Over the course of a project, the backlog is naturally going to grow and priorities are going to shift. The main appeal of agile is the ability to adapt to change quickly, but there comes a point where drastic change leading up to and during an iteration can have a negative effect on project throughput.

If the backlog is large and growing, it can get tangled and disorganized very quickly. Sometimes there’s just too much work to prioritize in a single backlog session. Here are a few tips to keep things orderly:

  • Turn the conversation towards what stories are going to bring the most value to the users.
  • Collaborate with the product owner and other stakeholders to determine what is truly the most important to pursue in the immediate so that the highest priority items can be staged for analysis. It is very important to hear everyone out, encourage discussion, and get consensus among the product team.
  • Once the highest priorities are identified, move them to the top of your backlog for staging so that they’re in immediate view (more on that further down).
  • If you know that there are stories that can’t or won’t be addressed anytime soon, move them further down. My personal preference is to bucket lower priority stories into general releases. We have a release staged for things that we know aren’t going to be pursued until next year and a release staged for what needs to be pursued this year. As we move through the iterations, more granular releases are staged.

2. Choosing a Theme

You might not be able to complete an entire epic in a single iteration or the iteration may be a hodgepodge of different stories. Work with the product owner and the stakeholders to group things into overarching areas where possible. A single user journey thread is ideal. This might mean moving stories out of epics and grouping them in different ways.

An example of this would be threading together stories for creating a data attribute, enabling it in the business user interface, adding it to reporting capability, indexing it in search, adding it to the presentation layer on a product page, and enabling it as a search facet. Here are some theme examples for an iteration:

    • Digital Asset Processing Enhancements
    • Product Content Interface Additions
    • Support Preview of Staged Content
    • Destroy Bugs Related to Data Synchronization

Sometimes your themes will directly align with your epics, but not always.

3. Getting a Handle on Analysis

There are many ways to approach analysis of user stories. Some teams include analysis as part of the time spent on a story in the iteration itself while others prefer to move the stories through a series of pre-work prior to adding them to an iteration.

Due to the complexity of our project, we find it necessary to put the stories through a series of steps before we deem it “ready” to be added to an iteration. We use JIRA statuses in workflows to move our stories through the analysis stages. Regardless of the tool used, it is important to apply a “definition of done” for each stage. Here are some examples:

    • In Analysis — Default status upon story creation. A stakeholder writes their story statement. The Business Analyst writes acceptance criteria and addresses open questions until everything is clear with the team. The Business Analyst can also consult with development on system capability to handle the request.
    • Acceptance Criteria Review — Official sign off by the requesting stakeholder that the requirements are clear.
    • Blocked on Analysis — Parked stories that need clarification to move it back through the other stages.
    • QA Test Authoring — QA engineers write their test cases for validation once Acceptance Criteria is approved. QA will use the test criteria to validate Acceptance Criteria is met once development is complete. This is also an opportunity to gain clarity from the Business Analyst or the stakeholder if needed.
    • Development Review & Estimation — The Development Team (Developers and QA engineers) reviews the story to ensure their understanding and provide their estimate in story points.
    • Ready for Development — Once a story is in the status it can be staged to be placed in an iteration.

This may seem like a daunting amount of work prior to making it to an iteration. You may be asking when the team will find time to do this when they have work to do in an active iteration. We’ll address this a little further down.

The most important takeaway here is that the entire team will need to collaborate to ensure the development of a story is set up for success. This practice keeps all parties engaged in the entire process. The “definition of done” in each stage is critical here.

4. Staging Iterations

Our preference is to have visual representation of the upcoming iteration at least. This should represent what stages of analysis the stories are currently in and who’s responsible for moving it to the next stage. Once the team gains momentum, it may even be possible to stage additional future iterations. We like to use Kanban boards where the columns are grouped by area of responsibility.

Remember those stories we staged at the top of the backlog? These are the stories to be analyzed in preparation for the next iteration in parallel with the active iteration. It’s ok to load this up heavily to keep the analysis workflow moving. If the volume of stories staged is too high based on capacity, then you can always move the remaining stories to the next staged iteration or into the backlog if the product owner decides to de-prioritize them.

This will give the product owner flexibility to adjust priorities as needed up until it’s time to start the next iteration. Implementing this practice narrowed down the focus on analysis and greatly increased the number of stories marked as Ready for Development.

5. Capacity Planning and Iteration Start

Before starting the iteration it’s important that we estimate in an appropriate balance of work that the team can actually complete. We need to know our capacity balanced against the team’s velocity for the last three iterations.

Story Point Estimation

One important contextual factor is that throughout the entire project we have used a baseline estimate for all of our stories using Fibonacci sequence. One story point is equivalent to one day of work across the entire team to complete a story (Design, Development,QA). For example, if the developers estimate 3 days work and QA estimates 1 day of work the combined effort would be 4 days.

Since the Fibonacci sequence goes 1, 3, 5, 8, 13 etc., we round up the story point estimate to 5 in this case. If a story is estimated at more than a 13, then we split the story up to ensure successful completion in a given iterations.

Many teams do not estimate with a baseline such as this, however, it has proven to be a useful tool for us in capacity planning. We continue to estimate this way.

Capacity

Iterations are two weeks in length, excluding weekends. That gives us 10 working days in a single iteration. The general capacity of a given iteration is based on the days multiplied by each member of the development team:

  • 1 Architect — 10 days
  • 2 Software Engineers — 20 days
  • 1 Front End Developer — 10 days
  • 2 QA — 20 days
  • Total Capacity — 60 days

Next we need to adjust for holidays and paid time off. Here’s an example for Iteration 35:

  • Offshore Team Holiday — 2 days each for the Architect, 2 Software Engineers, and 2 QA which totals 10 days.
  • PTO — 3 days for 1 QA Engineer
  • 60 days normal capacity — 13 days for Holiday and PTO = 47 days capacity for Iteration 35

Velocity

The number of story points completed in each iteration was:

    • Iteration 35–7 story points with 47 days capacity
    • Iteration 36–20 story points with 59 days capacity
    • Iteration 37–17 story points with 60 days capacity
    • Velocity and Capacity Average — 15 story points (rounded up) with 55 days capacity (rounded down) per iteration
    • Velocity and Capacity Ratio — 15 story points ÷ 45 days = .33 story points per day

The next iteration is expected to be a full 60 days capacity. If we multiply the velocity of .33 story points times 60 days capacity we get 19.8 story points for a single iteration.

Bonus Tip: You may want to adjust your story point ratio based on which team members may be out on PTO or holiday. For example, If you have two developers with overlapping time off, that means less throughput for QA to complete the work in an iteration. What is QA going to do with their extra time? They can write more test cases for stories that are in analysis and in our case they can get caught up on test automation for completed stories.

We have always used this capacity planning method, although we opted to reset for the next iteration because…

6. Executing an Iteration

Ultimately the team decided to reset expectations and agreed to complete 62 story points in the next iteration. We were able to do this because we created a more focused view of what needed to be analyzed and reduced the jumping around of priorities in the backlog. We had many more stories ready for development since implementing the analysis with Kanban.

Through our retrospectives and iteration analysis, the entire team agreed on the following for future iterations:

    • No adding stories to an iteration once it had been started. Previously, if stories were not marked as ready for development we would allow them to be entered into the iteration once they were ready to keep the team working. While it may seem counterintuitive, taking a “less is more” approach can settle things down a bit and lead to higher throughput over time.
    • The one exception is for hot fixes that were deemed to have severe production impact.
    • We opted to use the time remaining in an iteration for analysis of the upcoming iteration for QA to write their test cases, developers to document their technical approach, and for the team to provide story point estimates.

Once the iteration scope was agreed upon, we started Iteration 38.

7. Promoting Agile Principles

Ultimately your project is the result of teamwork and using sound agile principles are the key to success. Here are some tips that continue to serve us well:

  • The entire team is collectively accountable for results (not just the project leader).
  • Every team member should understand their role and how their contributions affect the success of the project.
  • Respect everyone’s time. Keep meetings succinct, well organized, and purposeful.
  • Use appropriate communication channels, especially with teams that aren’t co-located. A phone call can be far more quick and effective than a lengthy email chain.
  • Host retrospectives after every iteration to get candid feedback. Take it seriously. Every team member’s voice should be heard. Make changes when needed. Your team mates should be able to say just about anything (good, bad, or ugly) as long as they’re respectful to each other.
  • Celebrate successes and show appreciation to your team mates.
  • Promote self organization by providing tools that foster collaboration and individual initiative. Make information easy to find.
  • Host daily stand up meetings (15 minutes max) so that everyone is aware of what’s going on. Limit the discussion by asking each team member 3 questions: What have you done since the last meeting? What are you working on today? Do you have any blockers?
  • Operate transparently. There should be no secrets. Build absolute trust.
  • Remove impediments as quickly as possible when they’re brought up.
  • The team must agree to the work placed in an iteration before it starts. Present the scope, capacity and timeline considerations but ultimately the team should decide how much can be done.
  • Trust your team’s abilities and encourage them to ask for help when they need it. Let the team decide how the work gets done.
  • Embrace failure as an opportunity to improve. Fail fast, fail often, and learn. Be open to change.
  • Have fun!

The Results

We were astounded on how the changes we made significantly improved our productivity and made things better for everyone involved.

 

 

Iteration 38

 

 

 

 

 

 

Iteration 39

 

 

 

 

 

 

Iteration 40

 

 

 

 

  • We had many more stories ready for development including more detailed analysis from developers which contributed to faster burndown.
  • The development process went far more smoothly leaving plenty of time for analysis for the following iteration.
  • Team members were far more focused, engaged, and energized.
  • We significantly increased our overall velocity.
  • We gained far more predictability and were able to develop a solid product roadmap.
  • Planning meeting time was reduced because we had far more work analyzed.
  • Based on the current rate of throughput, we can add more work to future iterations.

This is just one example of how small changes can make a huge impact. Every project and team is unique but with more techniques in your toolkit you can help your team achieve their best.

Happy burning!

About Tacit Knowledge
Tacit Knowledge is a digital commerce consultancy focused on creating value for our clients by helping them consistently satisfy and delight shoppers across all channels and devices.