Accelerating Success: Decoding the Weekly Sprint Velocity of the International Mobile Team
“For a proposition to be considered valid and true, it must first be consistent.”
Appetizer
Before delving into the details of how we evaluate sprint velocity every week, I would like to provide some background information about the Mobile International Team.
As the Mobile International Team, we have split into two domains in the past months: Checkout and Discovery. The responsibilities of the Checkout team include managing the “My Account” page and its subpages, as well as the basket and checkout pages, among others. The Discovery team, on the other hand, is responsible for the homepage, product details page and its subpages, as well as the search functionality, among other tasks.
We use a common Jira board for both the iOS and Android domain teams. To ensure effective use of Jira, we have multiple epics in place. These epics help us distinguish the business concerns specific to the iOS team from those of the Android team, making it easier to understand and manage our respective tasks.
Why did we need this approach?
As mentioned earlier, the team recently underwent a split, which introduced new practices and challenges. Previously, we faced difficulties in tracking our weekly completion of Story Points (SP) because we had only one board where all colleagues worked together. The sprint velocity of the International Mobile team was calculated based on this setup, ranging between 80–85 SP.
However, after the split, some colleagues began supporting the checkout board while others supported the discovery board. With the introduction of a new board, we were uncertain about the number of SPs being completed and committed to each board.
What did we decide to do?
We wanted to track our sprint velocity and measure the number of stories we completed each week. To achieve this, we decided to share the information through Slack. Based on the data we gathered, we made a decision to discuss it during our retrospective meetings and focus on areas where action is needed.
As demonstrated in the examples below, we share the data with the team via Slack. During our retrospective meetings, we analyze this data to identify areas for improvement. Previously, while planning our backlog, we were unable to confidently state “we can achieve X SP next week” due to the lack of consistent data.
So, how do we interpret our Story Points (SP) and velocity?
Let’s begin.
Main
As a team, we conduct weekly sprints, and each domain has its own Grooming and Planning meetings. During the Grooming meeting, we prefer to analyze and evaluate the issues at hand. In the Planning meeting, we collaborate with the product owner to determine which issues we will address in the upcoming week, ensuring clarity on all aspects of the tasks.
So, how do we determine the target number of Story Points (SP) to aim for each week?
We utilize the velocity chart feature in the report section of Jira.
- This chart allows us to track the number of SPs completed on a weekly basis.
- We share this data with the team on a regular basis.
For example, you can observe how we share our SP data in both domains through the images provided below.
If there is a significant difference between the Story Points (SP) we committed to and the SP we actually completed, we adjust our workload for the following week. It is important to note that since the domain split occurred in the past months, it is normal for us to occasionally have weeks with more or fewer tasks.
Following this approach, we are now able to plan our:
- Technical tasks
- Business tasks
- UITest tasks
Moreover, we can better organize our Regression Tests and make them more systematic.
As a result, we have achieved favorable outcomes.
As depicted below, our completed data shows a rising trend.
Dessert
In addition to these practices, we strive to utilize the report section of Jira to its fullest extent. At times, we require specific data, such as the duration an issue has been waiting in the code-review column or identifying which issues have been blocked and for how long.
We share this information with the team to increase awareness and facilitate necessary actions.
Speaking of the columns on our Jira board, they are as follows: Blocked, Ready for Dev, In Progress, Code-Review, Ready for QA, In QA, UAT, and Done.
Through this approach, we aim to find answers to questions such as:
- How long has our issue been waiting in each column?
- Where is our bottleneck?
- Where do we need to take action?
- Which areas do we need to develop?
Here is an example of the data we have analyzed over time:
How long did our story tasks for the International Android epic wait in the Code-Review column on the IMC board?
Here is another example of the data we have analyzed over time:
How long did our bug tasks for the International iOS epic wait in the Blocked column on the IMC board?
Thanks to all this data:
- When we share this data every week, we can see the total number of Story Points (SP) completed as a team.
- We now have visibility into our velocity, whereas we were previously unaware of the number of SP we were accomplishing.
- With this knowledge, we can determine the number of tasks we can take on in the next sprint.
- We can identify the specific column on our board that requires our focus.
- We can recognize any areas where we might be experiencing challenges or getting stuck.
- By having access to this data, we can align all stakeholders at a common point.
- Moreover, I believe that as the data we commit aligns closely with the data we complete, our motivation increases. To maintain this close alignment, we strive to do good work every week.
What kind of data do you share with your team? Do you use different methods? Feel free to keep us informed through comments.
Thank you for your time. Please don’t hesitate to ask any questions or provide suggestions.
Want to work on this team?
Do you want to join us on the journey of building the e-commerce platform that has the most positive impact?
