Mapping Out the Daily Grind: Iteration Planning in Agile

Mapping Out the Daily Grind: Iteration Planning in Agile

Did you ever get your car repaired, and it ended up taking WAY longer than the person on the phone told you it would?

What’s to account for this sort of inaccuracy?

Sometimes the job is too huge and complicated to make an accurate estimate. Or else, the person making the estimate isn’t the same person who’s doing the work.

In any event, it’s a very common, and sometimes a very frustrating, phenomenon.

The agile planning process helps to fix these sorts of conundrums. It’s about breaking a project into small pieces, and carefully gauging the amount of work to take on during an iteration. This makes it easier to estimate how long a given amount of work should take.

Let’s look at the steps an agile team takes to plan an iteration. But first, let’s look at an overview of agile planning, from the big picture to the daily grind.

Peeling the Onion: An Overview of Agile Planning

The overall approach to agile planning, from the big picture to the granular, is oftentimes described with the metaphor of an onion. From the outer layer to the inner core, here are its essential components.

Strategic

Strategic planning is about setting direction and charting a course. This is the multi-year planning that looks at a company’s long-term goals. A method such as SWOT, that evaluates a company’s strengths, weaknesses, opportunities and threats, is one effective way to go about creating a strategic plan.

Portfolio

Given the course it’s charted, the company next determines where to put its labor and resources. At the portfolio stage, a company generates ideas and brainstorms specific projects to work on, as well as decides which projects to suspend.

Product Planning

The third phase is the realm of the product manager and other key stakeholders. It’s about looking at the market, identifying the customer’s problems, looking at competition, and planning specific products accordingly. At this stage, a company outlines product goals and builds a product backlog.

Agile project planning has more flexibility than a gantt chart. Although an agile map includes milestones, the development team pivots when it feels that altering the course would better serve the market and customer.

Team Level

With a definite product in mind, the team evaluates the work required to meet all requirements and bring the product over the finish line.

On its own, they organize this work into epics, features and themes based on the size of the work and how the tasks relate to one another. The product owner prioritizes this work in the product backlog.

Iteration Planning

Each iteration, or “sprint” in the scrum framework, is geared toward accomplishing work that really moves the needle for a project. The team carefully estimates how much work to take on during the iteration, which normally lasts about two weeks.

Daily Planning

Agile teams communicate daily throughout a project, and the daily meeting, or standup as it’s called in the scrum framework, is about discussing impediments, blockers, and assessing how the sprint is going.

As you can see, this “agile onion” looks at a company’s long-term goals, all the way down to the small daily duties.

While long-term objectives give direction to a company, the product goals may change as the team reflects on feedback from the end user, or notices shifts in the market. And although management and leadership weigh in on big-picture goals, the team has more autonomy as the planning becomes more granular.

Creating User Stories

Now that we’ve seen the big picture, let’s look closely at the inner-layers of agile planning: the team’s process of planning iterations and daily work.

The planning aspect of agile project management is a time consuming process, and entails breaking a large project into small pieces, then determining how long each task should take. An agile team spends 10% of its overall time planning and then reflecting on an iteration.

A user story is a small batch of work created with the end user in mind. Creating user stories is the first step toward building a product backlog, which is basically the agile team’s to-do list. Let’s discuss what it entails.

Define User Personas

The first step to creating a user story is to clarify the end user.

It’s helpful to brainstorm several types of end users, giving them details such as an age, gender, likes, dislikes and a background. All these details help identify the user’s problems and needs.

The creation of these personas doesn’t come from the development team’s imagination. Rather, stakeholders and product owners, who have researched the customer and the market, supply key information.

When the team has specific ideas about the customer, they’re able to create a product that solves real-world needs.

Gather Input From Stakeholders

A stakeholder is anyone involved with the creation of the product or anyone who is affected by it. This includes someone who uses the product, someone who interacts with the customer, business experts, the product manager, the marketing team and the development team.

Together, these stakeholders outline the product requirements, which are stated in the user stories.

Hold a User Story Session

With the end user in mind, all of the stakeholders, together, create user stories, including as many requirements as they can think of. These are put into the product backlog, and provide the team direction when planning iterations of work.

Each user story clarifies the end user, the requirement, and what “done” looks like. It’s given a point estimate to indicate the level of complexity.

While initially the user stories may outline immense tasks, they are broken down when planning iterations.

These stories are constantly being updated as the project progresses, based on the review at the end of the iteration and user feedback from any increment developed.

When all of the user stores are created, an agile team organizes the work and breaks it down. This gives them a sensible way to go about creating the product.

Decomposing User Stories With INVEST

When they’re first created, some user stories are so large and complex they’d take several iterations to complete. The team breaks down, or decomposes, a user story into tasks that can be completed in single iterations.

The INVEST approach outlines the criteria for determining if a story is suitable for one iteration.

Independent

The task must be independent from any other work. This means it can be completed all on its own, without having to work on any other stories.

Negotiable

The task isn’t laid out precisely. This allows for flexibility and interpretation during the iteration.

Valuable

The story is created with the end user in mind. Any potential user would be able to identify how the task adds value to them, or helps to solve their problem.

Estimable

The story isn’t overly complicated, and is easy to break down into individual tasks. This allows a team to gauge whether or not the work can be completed in the iteration.

Small

One individual story should be a small amount of work, something one developer could complete in half a sprint. This allows a team to take on several stories within one iteration.

Stories are measured in points, and a single user story generally never has more than 8 points.

Testable

And the final gauge for measuring whether a story is appropriate for an iteration is whether or not it’s testable. This means that the completed product has definite, clear metrics.

When a user story meets all of the requirements in the INVEST formula, this means it is suitable to include in one iteration.

Assigning Points to User Story With Planning Poker

After decomposing user stories, the team collectively assigns each task “story points” to measure its level of complexity.

One common method for estimating and assigning story points is the “game” of planning poker.

To begin this game, each member of the development team is given a stack of cards with Fibonacci numbers on one side. (Fibonacci are a rapidly increasing number sequence: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55.) They also select one small user story, and assign it an estimate (so a small number of 2 or 3), which becomes the baseline throughout the game.

As the product owner presents stories, the development team gauges the complexity of the story, comparing it to the base story. They place their elections face down on the table, then reveal the estimates at the same time.

The team members with the highest and lowest numbers discuss how they came up with their estimates. The product owner weighs in as well.

After this feedback, the team estimates again, up to three times, until they agree on a story point value to assign to the user story. Again, it’s good to note that story points aren’t measurements of time, but rather are measurements of a product’s complexity.

The planning poker allows each member, using their individual experience, to weigh in and gauge the complexity of the story. This ensures that stories receive an accurate point value, which in turn enables the team to select an appropriate amount of work during an iteration.

When assigning point values to user stories, a team needs to hone its definition of done. Usually, this entails more than completing the code, and may include processes for testing and reviewing increment before its release.

Experimenting With Iterations

When a team has a backlog of decomposed user stories, all with points assigned to them, it’s ready to select work for the upcoming iteration. The product owner grooms the backlog to determine the tasks with the highest priority.

Since the team is doing the work itself, they determine how much to take on during an iteration. Even when management is pushing to reach a milestone by a certain date, respecting this boundary is necessary for the agile team to be autonomous and self-motivated.

Agile is about doing, reflecting, then pivoting if necessary, and so it’s good for an agile team to experiment with a system for about three iterations to see what works and what doesn’t. Then it adjusts and tries something new, if necessary.

In a scrum framework, the scrum master’s objective is to get the team to a place where it estimates stories accurately and selects the right amount of work for a sprint.

In sum, the agile planning method is about breaking work down into small daily tasks, and allowing the person doing the work to determine their own workload. This autonomous, small-batch approach prevents cognitive overload, and allows the team to work at a steady pace throughout the project.