How we support Agile teams in estimates

The context for how we, Scrum Masters in R Systems, support our Agile teams in estimates is given by the specific challenges of the telecom industry. We activate in an industry where our software must be up 99.999% of the time, technology makes tremendous progress at a very fast pace and, at the same time, we need to comply with strict requirements for reliability, security and complex systems that require an adaptive change management system.

From the perspective of our telco operator customers, changes in technology come along with complex deployments, growing infrastructure and increasing number and variety of network elements. To support and transparently adapt to their changing requirements we need to integrate customer feedback early in the process through demos and presentations, and this is where Agile methodology comes into place.

How do we accomplish that?

Mainly by paying attention to quality assurance prevention techniques. We prefer to prevent rather than deal with bugs, and to shorten the bug fixing cycle, the testing and the customer acceptance phases, so we invest in requirements validation, in code review, automated tools for code coverage, in continuous integration, and in simulators whenever we don’t have real test systems.

Be it Agile or Waterfall, we still need to commit to timelines and build release schedules we can believe in and this is where estimation comes in. The funny thing about estimates is that developers see them as an ongoing process, whereas managers tend to regard them as definite values. Here are the steps we take, the questions we ask and the information we gather in order to set the same expectations and understanding and be able to plan a schedule.

We work in custom software development which means that every new project is a new challenge. Different projects can have similarities but they are essentially different and since it’s difficult to estimate things that we do for the first time, we have to use comparisons to potentially similar features – and some teams prefer to do that rather than start from scratch, although this can be misleading – or use expert judgement. In other cases it happened that velocity was different from one sprint to another so it was hard to predict how we will do in the next sprint.

For sure the classical bottom up or top down estimation didn’t work by itself and we can’t say that there is one estimation technique that has worked wonders for us, most of the times we used a mix of techniques.

Practice has taught us many useful lessons which I’ll share and detail below.

Lesson #1: Save time for learning

When we have to deal with new platforms, technologies or frameworks, during the first sprint we learn. Depending on the complexity and the team, during the next sprint we reserve time for learning.

Lesson #2: Distribute tasks wisely

Setup effort is smaller if one developer builds the project structure and then the whole team is brought on board. Specific work areas come with highly specialized expertise requirements.

Lesson #3: Plan for rework

When dealing with new technologies, we save time for rewriting, refactoring and redesigning where needed.

Lesson #4: Save time in a Sprint for regression testing

For complex products, we develop a regression suite that can grow with the project.  We start by identifying the needs, evaluate the specifics and technologies and then make an automation plan. We don’t estimate only how much it would take us to build the tests, but also maintain the regression suite.

Lesson #5: Account for bug fixing and re-testing bug fixes

Some of the things we learnt the hard way was that after first Sprints, effort for bug fixing needs to be taken into account, as well as testing of bug fixes.

Lesson #6: Have the QA start one Sprint behind the development team

Having the QA team start one sprint after the development team allows them to focus on features that were considered “ready for testing”. (“Done” concept means developed and tested)

Lesson #7: Know what comes next

In sprint planning it’s important that the developers not only ask the product owner what they’re going to work on during that sprint but learn in advance what is planned for the next 1 or 2 sprints.  This way we can put in balance effort and priorities and avoid returning to the same parts of the code.

Tips and tricks

  1. Use the work load pie chart report for an accurate effort distribution of the team members.
  1. Use a product backlog and sprint backlog
  1. Use a check list to refine your estimates, asking the following questions:
  • Have we done this before in our team?
  • Have we done this before in the company?
  • Is there anything free we can reuse?
  • In how many ways can we do it?
  • What is the best way to do it? Why?
  • Can we study this and regroup tomorrow morning for Sprint Planning?
  • At Sprint Planning, ask the Product Owner: any chance what we’ll be working on in next Sprint?

Estimates are an ongoing experience and once we complete a task or a sprint retrospective, we look at the tasks we estimated and those we completed and take a look at the variations. If it’s a big variation, be it positive or negative, you want to know why and the first question is how accurate was the data reported.

If the effort was reported correctly, in order to identify the reason for variance, we must answer another round of questions like:

  • Did you log the actual effort? How accurate?
  • What could you have automated?
  • How would you do it differently?
  • If you knew what you know now, how long would it take you? What about other colleagues?
  • Did we document what we did?
  • Did we contribute to internal twiki/forums/community?
  • Have we maintained historical data of the effort?

However, no matter if it’s Agile or Waterfall or a combination of more methodologies, we tailor and make the processes work for us. This is how we manage to deliver complex projects of more than 1,500 mandays with teams of 9+ people distributed in multiple locations, and how we manage to meet aggressive timelines while still putting quality first.

An example of solution we developed using purely Agile methodology is the configuration audit solution presented here.

This article is based on the live presentation delivered by Lucia Stoicescu, R Systems SCRUM Master and Project Manager, at the Agile Software Meetup Group in Bucharest.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top

Apply to this job

Contact us

Send your CV