In this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.
Agile Development is a software development methodology based on incremental, iterative development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.
Part V – Optimizing
Backlog Grooming (or Backlog Meet and Greets)
When teams begin to adopt Agile practices, they are often faced with sizing and committing to stories during sprint planning – when they hear about the stories for the first time. This can lead to onerous Sprint Planning meetings (where the team often loses focus and reverts to any means to get the meeting over with), unclear requirements, increased implementation risk and over- or under-commitment (depending on your team’s propensity for risk.)
While this is inevitable in the beginning, the key to Agile success is to begin to develop a ‘story horizon’ that’s longer than a given sprint. Ideally, your sprint horizon should be either a release (a subset of stories determined to meet a particular customer or market need that justifies a release announcement) or 2-3 sprints. Grooming the backlog beyond this will often lead to discarded work as requirements change or evolve.
If your planning horizon is a release, I recommend taking 1/2 day for a Release Kick Off meeting at least 2 sprints prior to beginning the implementation. During this meeting (ideally held offsite) the Product Owners will walk the whole team through the goals, features and expectations of the release. This may include performance or scale metrics that must be met (e.g. must be able to handle n concurrent users or x,000 transactions/second). Once the team understands the overall objectives, the Product Owners will walk the team through the backlog as a series of high-level stories. The team will seek clarification and discuss possible implementation approaches. This meeting should not seek to fully understand or to size the stories, but rather to establish common ground and to uncover issues or questions (technical, requirements, etc.) that need to be addressed before a story can be sized.
Once the Release Kickoff meeting is complete, or if you are just working through a backlog of stories and releasing incrementally, you should plan to spend at least 1 hour per week grooming the backlog. During this time, the team will begin with a brief high-level review of the backlog before discussing and sizing (previously unsized or deferred) stories from the prioritized backlog. If issues arise that prevent a story from being sized, it will be deferred and flagged for the next grooming meeting.
Backlog grooming is an incredibly worthwhile exercise that sets aside time to ‘meet and greet’ upcoming stories in advance of their implementation. It provides developers and QA valuable time to consider upcoming stories, to discuss ideas offline and to improve the quality of their estimates. Schedule a fixed day/time every week for backlog grooming and make it a priority for the team (I prefer Wednesday mornings – since they avoid Sprint Planning and wrap up activities.) Despite their protestations of ‘too many meetings’ the team will quickly appreciate and value the impact of the investment.
In traditional, waterfall, processes schedules often comprise developer and QA estimates (measured in hours or days). Data is then plotted on a Gantt chart that includes a contingency factor (%age overhead, based on prior experience of the team’s sustained productivity), vacation days, holidays, etc. Progress against goals is measured in %age complete vs. estimate. Also, development time is often estimated individually per feature and separately from QA – with little or no accommodation for issues that will arise during integration and testing. This approach is fraught with difficulties that often lead to schedule overruns. One example is that when asked for an estimate of %completed, developers often give an answer that is better described as %time spent: “I’ve spent 80% of the time, so I’m likely 80% complete”. This often has little or no bearing on the actual level of completeness (remember the old 80-20 rule?) and introduces the risk of discovering schedule overrun late on the project.
Agile follows a timeboxed approach, where the team makes a commitment to completing product increments (stories) within a given timeframe (see Establish a rhythm for the team).This is a significant shift in thinking for many teams and is often hampered by them regressing into traditional estimating and trying to plan the sprint duration using traditional methods.
To shift the team’s thinking, I recommend introducing the concept of relative sizing. That is, estimating the size of a story (including everything required to deliver a functional product increment; Development, QA, Documentation, etc.) relative to other work. To get teams started, I introduce relative sizing using a number series that closely resembles the Fibonacci scale (1/2, 1, 2, 3, 5, 8, 13, 20…) ). As a point of reference, I associate the smallest increment (1/2 point) with some piece of work that everyone in the room can grasp. For example, ‘1/2 point represents the work required to make the smallest change to an application’: think changing a label on a UI. The 1/2 point sizing includes code changes and check-ins, developer testing, QA setup and testing, and refreshed screen shots. The size of every other story is then calculated relative to this.
Progress is then measured during the sprint in completed stories (those that are ‘done’.)
Planning Poker is an estimating exercise that helps to maintain the objectivity of story sizing by reducing the influence of any single member of the Scrum team on the sizing or others. You can purchase Planning Poker Cards inexpensively, or download a Planning Poker App. Just make sure that everyone committing to the sprint has the ability to contribute their size estimate (even if it’s just using a piece of paper with the number sequence, or fingers and toes!)
The team collectively discusses each story, seeks clarification from the Product Owner and formulates a high level approach to deliver the product increment. Technical or other risks are discussed and QA voices how they will acceptance test the feature. The Scrummaster then asks everyone to estimate the level of effort (using relative sizing) to complete the story and every member of the delivery team privately selects a ‘card’. I like teams to countdown “3, 2, 1” to ensure that everyone is ready then ask everyone to hold up their ‘cards’ at the same time. Typically, there will be a lot of consensus in the room on the size of a given story. However, it’s important to look at the outsiders. For example, if the bulk of the team estimates 8 points but one member holds up a 20 and another a 2, there’s likely something interesting to pursue. Ask open-ended, non judgmental questions of the ‘outsiders’ “That’s interesting, why a 20?” to understand their reasoning. In my experience, their reasons are often very valid and affect the resulting points sizing. In the example, it could be that the extent of testing has not been considered by the bulk of the team and that the size needs to be increased to accommodate the additional work. Or, the effort to implement could be much smaller because it can leverage work thats already been completed that perhaps only one or two people are aware of. In either case, take the time to hear each of the perspectives, have the team discuss and re-size the story.
The insights gained during planning poker are often really valuable and will improve the quality of your estimating. The key is to remember that Planning Poker is not designed to force everyone to a common score, but to gain a common understanding of the work involved and to base the size on their best collective knowledge.
Identifying Latent Impediments
While the Daily Stand up is intended to uncover issues that are impeding progress (“do you have any impediments?”, it’s often not as simple as asking the question. Team members always want to show that they are doing their best to demonstrate progress. Admitting to being ‘stuck’ or ‘unclear’ can amount to feeling vulnerable, like they are letting the team down (this is especially true in nascent teams.) It’s the Scrummaster’s responsibility to uncover these ‘latent impediments’ and to help determine a path forward.
Key indicators of latent impediments are:
- Tasks not moving across the board (remember, tasks are estimated to be 1 day or less – if they are not moving daily, you likely have an issue)
- Developer or QA giving the same update in two or more scrums, often with the words “I’m about to reach a breakthrough”
When a latent impediment is identified (or even suspected), the Scrummaster can ask for a team member to help with one or more next steps to accelerate a breakthrough:
- Pair programming
- Revisit Task Breakdown (it may be that issues or ideas have emerged since the original task breakdown that affect the implementation approach)
- Code review
While it may appear that the Scrummaster does not ‘trust’ the process, the opposite is actually true. The process is highlighting the fact that a problem is building. Addressing it quickly will help keep the sprint on schedule and will continue to engender teamwork, trust and openness.
As a product matures, the effort to regression test existing functionality increases with every release. Manual (black box) regression testing becomes increasingly labor intensive and prone to error. Like Unit Testing, QA (functional) test automation will pay significant dividends and will allow your limited QA resources to focus on usability and ‘feel’ of the product, rather than performing repetitive testing.
I recommend using a scripted, data-driven test framework like Selenium or Watir to give you maximum flexibility.
Begin to make progress by adding automation stories to the backlog, prioritized based on risk and ‘bang for the buck’. That is, start with functional tests for the most fragile areas of code (those known to break often) or the most cumbersome parts of the regression testing (multi-browser, multi-setup). The key is to make at least some progress on QA automation every sprint to build out a portfolio of automated regression tests that can be run as part of every build to identify functional bugs at the earliest (and cheapest) opportunity.
Investing in optimizing your Agile process will result in greater team confidence and reduced delivery risk. It will necessarily require a commitment of time that will impact your team’s velocity initially. However, the increase in clarity and common understanding will more than compensate in the results achieved.
And, while you are implementing new ways to increase the productivity of the team, take a moment to reflect on how far you’ve all come. You’ll be pleasantly surprised…and it’s another reason to celebrate!