EXPEDIA GROUP TECHNOLOGY — SOFTWARE

Thank God It’s Friday…

A journey through an Agile sprint

It’s Friday, the last day of our sprint. We all presented our demos yesterday. What a fun day it was to celebrate our accomplishments of the past three weeks! It was really awesome to see how each team member wore their creative hat and came up with amazing presentations and, of course, working software.

We’re immensely passionate about Agile, and today we are going to start our day with the ceremony of sprint planning. Agile is about collaborating to deliver the highest value per product increment, with high quality, as quickly and as frequently as possible, and continuously improving the delivery process. At the core of Agile, organising and cross-functional teams use practices appropriate to their context to create solutions through collaboration. Our team is no exception. Oops — it’s already 9:30 and everyone’s in! Let’s zip through the ceremony and the various metrics we will use in this ceremony:

Capacity planning

Let’s take a look on our team’s availability over next three weeks. In this metric, we check for the available hours for each member, taking into consideration of any planned leaves, trainings, non-project team meetings, etc. When we are clear about the total available hours each individual can contribute in the upcoming sprint, we can move on to the next metric.

Workload pie chart: original estimate

Now that we know the total number of hours that we have in our next sprint and available hours for each of our team members, we will refer to the product backlog. Once the user stories have been broken down into subtasks and each subtask’s effort has been estimated, we’ll start pulling in stories from the prioritised backlog. While we pull these stories, we keep monitoring the workload pie chart to ensure that work is distributed in proportion to the available hours of each team member. Nobody in the team should be over-committed, making them feel frustrated, nor is anyone under-committed, ultimately leaving them disengaged.

Workload pie chart

As we are populating the sprint backlog, the other metrics we track are the velocity chart and commitment reliability chart

Sprint velocity

We refer to the velocity chart to make realistic and achievable commitments. This chart represents velocity in terms of the story points we can complete in each sprint. We take the average velocity from previous sprints and aspire to be as predictable as possible by committing to same/greater/lesser story points depending on data from other charts (such as availability and commitment reliability).

Sprint velocity

The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the forecasted and completed work over several iterations — the more iterations, the more accurate the forecast.

We know our velocity, but do we know how reliable our commitments are? Let’s check in our next chart.

Commitment reliability

This index determines how reliable the team’s commitments are. We multiply this by the average velocity to identify the number of story points we should commit to in the next sprint to ensure the highest possibility of meeting our commitments. If our commitment reliability is below 100%, it signifies that we are missing on our commitments and we should lower our commitment for next sprint. But if we are exceeding the commitments, the index will be above 100%, allowing us to flex our muscles and push our limits by pulling in some additional stories, resulting in an increase in our velocity.

Commitment reliability

Around three or four hours have passed now, and finally our sprint is ready to be started on Monday. As we progress through the day and the weekend mood has started to set in, there’s one last thing that we must do just before we wrap up our week. Post lunch, we swarm together to conduct our sprint retrospective. It’s time to reflect on our team’s performance over the past three weeks. One of the key benefits of being disciplined in execution is achieving marginal gains. Each time you execute and deliver on something, these small wins, when multiplied together, compound their effect. This results in forward momentum, cadence, and rhythm. Join me and my team to see how we conduct this meeting and various metrics that we refer to.

Happiness index

Have you ever been part of a highly-motivated, high-morale team?

If you have, chances are that most days, you were happy to come to work. You were focused and enthusiastic. You enjoyed collaborating with your colleagues and, together, you worked hard and came up with some great ideas.

This is quite a unique metric that gives some great insight into our team’s morale. Once everyone is settled, I, the scrum master, start our meeting by giving a brief overview of our sprint. I will now ask everyone to rate the sprint on the scale of 1 to 10. This number should reflect how they feel about the sprint in general. This helps to gauge the team’s pulse on how engaged and happy they felt during the course of the sprint. Positive, highly motivated teams are fun to be a part of. And they can accomplish far more than teams that struggle with negativity and low morale.

Happiness Index

Now you may be wondering why this is so important for us. We all know that happy individuals are more successful in many areas of their lives, especially at work, compared with those who struggle to find happiness or to think positively.

Positivity increases our ability to think creatively, to progress in our careers, to cope with challenges, and our adaptability to work with other people. It can reduce absenteeism and staff turnover, and lead to more satisfied and productive teams. In short, it’s an essential ingredient for success!

The more positive emotions we experience, the more likely we become to exhibit other positive behaviours, such as curiosity, awareness and innovation — and this applies to groups, as well as individuals.

Great! So now we know the pulse of the team. Let’s move ahead and analyse various charts, e.g., velocity, commitment reliability, burndown, and give the team some quantitative insights for data-driven discussions on questions like:

1. Were we be able to meet our commitments?
2. Was our burndown of work steady throughout the sprint?
3. Did we pull in any additional work?
4. Was there any work that we could not complete?

The goal here is to understand how our forecast was compared to actual delivery. We also analyse the trend of our team’s velocity: whether it’s upward, downward or constant. Once we have enough insight into the sprint, we are now ready to brainstorm on

1. What went well
2. What could have been done better
3. Any action items/takeaways/suggestions

This aligns with the Agile principle of having the team retrospect and tune their behavior. The team interacts and conveys information and maintains a constant pace indefinitely. So committing to some agreed-upon action items to improve in the next sprint, the wonderful Friday has now come to an end and it’s time to wrap up the work. Happy Weekend!!! See you on Monday…

Photo by Lance Asper on Unsplash

Come Monday…

Blink your eye and a weekend has flown by.

Happy Monday morning everyone :)

Fully rested over the weekend, our team is now ready to swing into action. Our new sprint has started. With full enthusiasm, we kick off our sprint with our daily scrum. A key Agile principle is communicating face-to-face whenever possible, so the daily scrum is also an opportunity for the team to interact face-to-face and collaborate. Strongly resisting our urge to ask questions, we try our best to stick to just three asks:

1. What did you accomplish since the last check-in?
2. What will I be working on today?
3. Do you have any blockers?

All other discussions are placed in the parking lot, to be taken care of at the end of the scrum with the concerned team members. As the sprint progresses, we run daily scrum meetings and use our board to go through all the updates. The expectation is that everyone will update the board before coming to scrum so that the two charts that we refer during our scrum are fully up to date. These charts are:

Burndown chart

During the sprint, we track the burndown chart, which depicts the amount of work accomplished versus work remaining in hours. The x axis represents time, and the y axis refers to the amount of work left to complete, measured in hours.

1. The grey line signifies the amount of workload that should be reduced over the course of sprint ideally
2. The red line shows the remaining work

3. The green line defines accomplished work

Burndown Chart

Some of insights we draw from this chart:

1. If the red line is hovering below the grey line, we will be comfortably able to meet our commitments. If it’s hovering above, we are at risk of missing our commitments.
2. At the middle of the sprint, there has to be a breakeven where the red line crosses the green line, which shows that we should be able to complete our sprint at a regular pace. If this crossing happens before mid-sprint, then we will meet our commitment early and as a scrum master, my role is to ensure we have couple of stories ready in the backlog we can pull in if the team has extra bandwidth. However, if this crossing happens after mid-sprint, we may miss our commitments and my job becomes keeping the stakeholders informed of the risk.
3. If there are any blockers, we can inform the product owner and they can in turn engage our customers.

Workload pie chart: revision Wednesday

Keeping an eye on this chart helps us to identify if the workload is evenly distributed among the team members. If there is a need, we can reshuffle the work so that we can meet our commitment as a team at the end of the sprint.

We do backlog refinement every Wednesday with our product manager. It’s an ongoing scrum team activity to prepare the product backlog items for future sprints.

Hours get converted into days and days get converted into weeks and juggling between our stories, we do not even realize that how quickly the three weeks have passed, and the time has come for the most exciting day of the sprint, sprint demo. As working software is a primary measure of progress, every Thursday of our last week of a sprint, we conduct sprint demos to let the team present the work they have built in the current sprint. Agile’s highest priority is to satisfy the customer through the early and continuous delivery of crucial products and services. Hence this is the time not only to showcase and celebrate our accomplishments of the sprint, but also an excellent opportunity to present the working software in front of our customers and gather their direct feedback.

But can watching working software be fun, exciting, and entertaining? You bet! My team celebrates its demo day. It’s like binge-watching a captivating web series. And it’s indeed mesmerizing to see how far some of the team members go to make their demos interesting.

Finally all demos are done and everyone is feeling contented and proud of the value they have added for Expedia Group™, one brick at a time. Imagine how you would have felt after dancing your heart out during a super fun party with your friends and family!

With the same feeling we kiss the day goodbye — As tomorrow,

Thank God It’s Friday…