Time management or in simple words „planning“ can be one of the most important things you learn in your life. Have you ever thought „I just lost an hour of my life and I will never get it back“? You probably have, quite a few times. Time management is often associated with business, but this skill proves to be useful in every aspect of life. And then there are those jobs – like the world of a Project Manager – where time is always of the essence.
After rejoining Playtech a year ago, I took the role of a Data Services and Reporting Dev Ops Team Lead (isn’t that a cute long title for a position?) and Scrum Master in IMS. (IMS is Playtech’s Information Management Solution, the most capable player management system in the gaming industry and the power behind all our products.) In practice, my position is like a technical secretary between multiple teams and departments within IMS. And I have to say that this is an intriguing job to do, especially at Playtech – no routine whatsoever!
We have the Tallinn and Tartu Development teams, Report Engineers, Quality Assurance and DevOps team – in total, I handle 5 different teams under Data Services and Reporting within IMS unit. And mostly we’re dealing with Regulatory Reporting which means that our job is to provide numbers that are always correct to gambling regulators, operators, and our licensees from all over the world.
The ever-lasting planning challenge
One of the key challenges in Data Services and Reporting is how to plan the most efficient way of working in future Sprints and how to add visibility for the Project Management team. A Sprint is a short, time-boxed period when a Scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches.
The challenge planning Sprints in the best possible way goes back a long time. Most of the time when entering a Sprint, we were confident that we did Sprint planning well and our estimations were going to be correct. But in the end we somehow only managed to execute a third of the planned items. And on top of that, in such cases we ended up finding out that some team members are going to be on a planned vacation or attending a training during the entire week of a Sprint. This meant that many planned items still remained uncompleted and we needed to postpone items to the next Sprint. The Project Management team was not happy either, needing to constantly revise the Sprint plans.
The diagnosis to the situation was obvious – as a Team Lead and Scrum Master, I stood in the middle of an organized chaos, facing a great time management challenge. So what tools could I use to wrangle the chaos out of our planning?
My fours steps journey to efficient planning
In my shiny news shoes of a Scrum Master, I first decided to address this challenge, following standard Scrum methodologies. After a while I understood that they are not enough for us. Standard Scrum methodology involves many Scrum events like daily Stand-ups and one Development Team with a maximum of 9 members. But we have five different teams in Data Services and Reporting and most of those teams are influenced by the availability of Quality Assurance, because the individual teams are not doing QA in most cases. (Although, when resources are exhausted in QA, it’s basically all hands on deck and they can do their own QA, if needed.)
My next attempt was trying to leverage all Jira functionalities that are available, starting with time estimation. This, in turn, led us to multiple issues. For example, we saw that providing estimates with a specific time commitment put our engineers under considerably more stress. Also, cases occurred where we were providing incorrect time estimations which leads to under- or overestimated Sprints.
The third approach we used was estimating work with Story Points. As I have worked in a company that used Story Points efficiently, this kind of an approach was the next logical step for me. Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. Using Story Points helps us to quickly estimate issues, without making a specific time commitment, while embracing the uncertainty that comes with estimation. Yet Story Points are accurate enough to plan for Sprints ahead of time.
So, after establishing this approach we achieved more accurate Sprints and a better forecast for Project Management than ever before. Although, truth be told, we continue to struggle with comparing Story Points against time estimation. Practice makes perfect – it should start working as we gain more experience.
Never stop striving to be better
After a while, we realized that we can do even better than what we are capable of today. We are already able to plan Sprint content more accurately than before and we can present a more accurate forecast of work to Project Management. But the only obstacle we needed to overcome was Jira itself. Jira isn’t meant to handle “multiple teams” in “one team” which means we couldn’t make different Projects for each sub-team, because the whole huge IMS unit was using the same Project base.
Marko at our summer days - Playtech Bootcamp 2019
As I have always liked puzzles and challenges, I decided to build an additional web application where I can define departments, teams and people who participate in Sprints. We named this web application very succinctly the “IMS Planning Tool”. It is developed in PHP, NodeJS and using PostgreSQL to store meta and statistical information, all packed into a Docker image. The data is fetched and pushed over the Jira API. The IMS Planning Tool has two primary topics: Planning and Grooming.
How to Plan & Groom efficiently
On the Planning part, we can choose between different Sprints to start planning, add Estimation Goals and missing (vacation) days to the Teams and finally drag and drop issues into the Teams’ columns. There is also an indicator that shows if you are under- or overestimating a team. The indicator will get more precise after every Sprint, acting a bit like a basic AI. Using this tool allows us to be more accurate than ever.
The second important functionality of the tool is Grooming. Before COVID-19, I started developing an internal virtual Planning Poker game which we usually played with physical Planning Poker cards.
Planning Poker is an agile estimating and planning technique that is consensus-based. To start a poker planning session, the Product Owner and Team Leads point out important topics to develop and describe a feature to the estimators who are usually Software Engineers. Each estimator is holding a deck of Planning Poker cards with values like 1, 2, 3, 5, 8, 13, and 21. These are the sequence we recommend for Story Points. Story Points reward team members for solving problems based on difficulty, not time spent. This keeps the team members focused on shipping value, not spending time.
The estimators discuss the feature, asking questions of the Product Owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time. If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After a further discussion, each estimator re-selects an estimate card, and all cards are again revealed at the same time. The poker planning process is repeated until a consensus is achieved or until the estimators decide that the agile estimation and planning of a particular item needs to be deferred until additional information can be acquired.
After the pandemic landed in Estonia and we switched to working from home in just a day, we needed to start playing virtually. The game is simple, one person creates a room and then others can join and start estimating Jira issues that are listed in the “Grooming Sprint”. Every action takes place in real-time, so every player can instantly see feedback from others. Every player can give estimates in basic Fibonacci numbers. After a score agreement, it will be synced into Jira and we can start the Planning of those items. To add a bit of fun to Grooming, the card decks are randomly covered with cat GIFs.
Having used the Planning Tool for a while with 5 teams I handle that include 21 people, we managed to get our Sprints very accurate, achieved better visibility for Project Management and also gained useful feedback from statistics. As a bonus, my team members are less stressed and we can say that the harmony we strived for has finally been achieved.
Less and less items are postponed to the next Sprint. By today, we have even managed to clean up the old Sprint items from Backlog. This is a huge victory illustrating vividly the strides we have made in getting to grips with Sprint planning and fighting the chaos that goes along with it – all in a span of a single year. Never underestimate the importance of effective time management as it is one of the pillars for happiness at work as well as the main source of joy from finally getting things done in time.
