The 5 Key Elements To Successful Agile Sizing

In this session, we will discuss the challenges of Agile sizing, Epics, Stories, Tasks, and Spikes. We will start the discussion by defining the Agile components and then discuss the different sizing processes used and the thought process behind the philosophies.

We will build upon the concepts we learned in the requirements discussion and discuss how quality is incorporated into the agile objects.

Your agile journey to success

Remember this content is part of a 7-part series that aim at addressing Agile from a software quality point of view while providing solutions to the most common software development pain points.

👉 Agile Requirements Gathering

👉 Agile Sizing (Epic / Story / Task)

👉 Testing Manual vs. Automation

👉 Test Asset Management 

👉 Automation Scriptwriting 

👉 What is a quality gate, how to use

👉 KPI

In our first episode about Requirements, we saw their importance in developing quality software and how you can make an impact as a QA engineer. 

Background to agile sizing

Any discussion on Agile needs to start with the understanding of respecting our fellow team members, and a willingness to actively communicate information amongst the team.

When discussing agile sizing techniques, understanding how the project is time segmented is helpful. Generally, teams use the terms iteration and sprint interchangeably. The Agile team sets the length of time allowed for each iteration. The most common length of time for iterations is 1-3 weeks. In rare cases, or when a team is first changing from waterfall to Agile, they may try 4-week iterations. Teams that try 4-week iterations may find they are practicing iterative waterfall. For our discussion, we will assume 2-week iterations. We will come back to this later in our conversation.

#Backlog

is the list of things that need to be completed on the product, the list is used to pull epics and stories into the project iterations when the timing makes sense. Generally, the backlog comprises Epics and Stories.

#Epics

are direction settings in software development. They generally encompass a feature delivery. The work encompassed in an Epic may not be complete within a single iteration. An Epic may contain one or more stories. To be considered complete and mark the Epic closed, the testing tasks need to be completed, and customer acceptance that the completed Epic meets the specified requirements. All Stories associated with the Epic have to be marked complete to close the Epic.

Going back to our XBOSoft Talk session on requirements where we used the “building a house” analogy, an Epic would be defined as the roof, the external design of the house, the first-floor plan, second-floor plan, etc.

#Stories 

are limited to a narrowly defined scope of work that can be completed within a single iteration. To be considered to be complete and mark the Story closed, the testing tasks need to be completed, and customer acceptance that the completed Story meets the requirements specified at the beginning of the iteration.  All Tasks associated with the story must be marked complete to close the Story.

Continuing with the house analogy, a story may be defined as installing a front door, installing windows in the living room, or installing center stairs. A story is a chunk of work that can be completed and tested within a single iteration.

#Tasks

are defined within the story. A story can have one or more tasks. Tasks are defined as work within the story and may be assigned to multiple team members.  From a software delivery perspective, a story may have a business analyst task, a systems analyst task, a development task, and a quality assurance task.

In our house analogy of installing the front door, the tasks may include:

– Purchasing the front door 

– Taking the delivery of the front door 

– Installation of the front door 

– Painting the front door 

– Installing the doorknob, lock, and knocker 

– Testing that the front door opens, closes and locks without issue

#Spike  

is a research area. It can be around a new feature, technology, or process. Depending on the subject area’s broadness, it could be classified as either an Epic or a Story. Part of determining how to classify the Spike is whether it can be completed in a single iteration and the estimated effort. The Spike is purposely vague due to its exploratory nature and may carry over between iterations without penalties.

Agile sizing illustration

We will assume the Agile team is working on a two-week sprint for our discussion. A two-week iteration (sprint) generally contains ten business days. The iteration (sprint) planning needs to consider team member availability. A common challenge when a team is starting with Agile is to think whether each team member will be able to give 40 hours/week or 80 hours per iteration (sprint). For each sprint, the agile team needs to review availability due to holidays, vacations, and training and determine how many stories they can take on for the iteration. A general rule of thumb is that if a person is scheduled for an eight-hour work day, they will have six hours of availability.

What is QA’s role in the agile sizing process?

All the team members have a responsibility when a story is accepted into an iteration to:

• Contribute, ensuring requirement specifications are clear and complete
• The Story can be built to meet the specified requirement
• The Story can be tested as specified
• The Story supports the larger objective of the parent Epic. 

Quality and testability of the story should be considered at Story conception, re-evaluated when the Story is accepted into an iteration, and verified before the Story is closed. 

Impact of agile sizing on team tasks

On many Agile teams, team members are encouraged to explore skills beyond their initial skill set. For example, a Quality Engineer may take on business, system, or development tasks. A Business Analyst may also take on system or quality tasks. Finally, a System Analyst may take on business, development, quality tasks, etc.

The question in agile sizing becomes how to size the chunks of work to determine how to classify them.

T-Shirt agile sizing method 

Let’s understand T-Shirt sizing and its applications. 

What is T-Shirt sizing – chunks of work (XL, L, M, S)?

Similar to folded clothing, the iteration length is fixed, like the size of the dresser drawer is a fixed volume. XL T-Shirts take more space than Small T-Shirts in the drawer. XL Stories take up more of the capacity of the iteration, Small Stories take up less capacity. The key to a successful iteration (sprint) is to find the optimal combination of the different size objects to use the full capacity available in the iteration (sprint), while avoiding carry-over stories from one iteration to the next.  Going back to the dresser drawer analogy, think about having the dresser drawer full with neatly folded clothes but not overflowing.

Extra-large (XL) story 

has the potential to be too large to be completed in one iteration (sprint). The team will potentially want to look at how this can be broken up into multiple stories. For example, the original item might become an Epic, and the stories will be spread over one or more sprints. An Extra-large Story may estimate 50 – 100 % of the iteration capacity.

Large (L) story 

may be able to be completed in one iteration. However, suppose it contains tasks that must be completed in a specific order due to dependencies. In that case, the team must decide if the story needs to be split into multiple stories to fulfil the story being complete in one iteration requirement.   A Large Story may estimate 40 – 75 % of the capacity.

Medium (M) story 

Should be completed in one iteration. The order of the tasks within the story and when the story can be started in the iteration (sprint) needs to be taken into consideration to determine if the story can be completed within the iteration (sprint). If the team wants to start an M Story but does not feel they can start the work early enough in iteration (sprint) to complete the story, then they should break it into two stories. A Medium Story may estimate 10 – 50 % of the capacity.

Small (S) story 

should be completed in one iteration. A Small Story may estimate out at greater than zero – 20 % of the capacity.

Points sizing methods 

The team comes to a common understanding of what a point signifies and then assigns points to chunks of work. Points can be attributed to the effort. For example:

• 1 pt = 8 hours of duration to complete all tasks) or,
• Elapsed time (1 pt = 1 day of work, including all other commitments in a day).

What does agile sizing imply for the team?

The Agile team needs to come to a common understanding and apply their measurement consistently. Although it may take a new team 2-3 iterations to understand their cadence and take on the correct number of stories to be able to complete an iteration. The goal is not to have any stories selected for the iteration (sprint) carry over into the next one, therefore having a backlog of stories to pull from for future iterations. Many common agreements state that credit for work on stories in an iteration (sprint) occurs when the story is closed. However, if the story has outstanding tasks, it is carried over to the next iteration.  

This is similar to the concept of minimizing Work In Progress, the Just In Time concept in manufacturing that was imported from Japan in the 80s to reduce inventories while also increasing production speed and quality in automobiles.

Continuous improvement in agile

One of the key benefits of an agile team is learning from previous iterations. A key component of an iteration is a retrospective whereby team members discuss what they could improve. In doing so, one of the most common areas for improvement is defining work (AKA Definition of Done) and understanding the team’s capacity to complete work. If it over-estimates its capacity, it will either experience overtime to complete the iteration, or the story (or perhaps task) will carry over into the next iteration. Therefore, many Agile teams track their story attempt/completion (also known as velocity) and report during their retrospective ceremonies along with what methods or ways they can improve for the next iteration. This is why sizing, estimating, and retrospectives are such an important part of the Agile process in fostering continuous improvement via short iterations and feedback. Who wants to work overtime all the time because they underestimated the work or overestimated the capacity of the team.

Speed of delivery vs Quality in agile sizing

In any case, it’s important to keep the big picture in mind – deliver higher quality software faster. What does this mean? Being facetious, do you want quality software delivered slower? No. Do you want poor quality delivered faster? No. How about equal quality delivered slower? N. Equivalent quality delivered faster? Maybe. Let’s look at these options using a simple matrix.

As you can from the simple 2D matrix, of course we want the green, better and faster. And of course, we don’t want the red options (worse quality and slower, same quality and slower, and worse quality at the same speed). Examining the remaining options, we probably don’t want slower and better, but perhaps. We may be happy with better quality, at the same delivery speed. We certainly don’t want the same speed and same quality, but we may be happy with equal quality and faster. 

Find what you break and fix it

This seems like a simple exercise, except when you get to the last option, faster speed at worse quality. This is what baffles many teams that get on the agile bandwagon to discover that perhaps they can do things faster, but their quality goes down. We seem to mistake Mark Zuckerberg’s words of  “move fast and break things” for entrepreneurial endeavors and apply them to software development. It does actually if you know what you break and make intelligent decisions on what to fix, what to get rid of, and what to swap out. This is where quality comes in and you can’t push people to produce software functionality without regard to quality. Quality needs to be built in which means that although you may not have dedicated testers on an agile team, you still need testing tasks. It’s great to “move fast and break things”, but probably better if you find what you break and fix it.

Agile sizing in summary 

The key learnings from this session:

• There is a one-to-many relationship between Epics and Stories, Stories and Tasks.  
• Stories and Tasks should be actionable work that can be completed within an iteration (sprint).  
• The agile team needs to decide how they will chunk the project’s work and apply a standard measurement process (T-Shirt, Points – Duration, or Effort).
• Spikes are exploratory in nature, can be an Epic or Story, and results will be reflected in future actionable work.
• Epics and stories should contain quality tasks. Therefore, quality should be built in from the beginning.
• Iteration completion statistics are tracked.  We will talk more about Agile reporting in the talk about KPIs (Key Performance Indicators).
• Understanding the team’s capacity to take on the amount of work that can reasonably be completed within an iteration is important. That adjustment will avoid story carryover or overtime to complete the work.
• Accurate story sizing and estimates are important to the team developing a sustainable candace of each iteration, which helps the team avoid working to a deadline, helps to develop communication and trust within the team.

Thank you for taking the time to learn more about Agile Sizing. 

Don’t miss the next episode.

In the next XBOTalk episode, we will explore Manual vs. Automation Testing and what makes a good candidate for automation.

Please contact us at XBOSoft if you have any questions or want support from our many experts.

Discover “The Best Guide To Agile Requirements Gathering” NOW!!!