Initial problem

At the first meeting with the key stakeholders, they pointed out that their main challenge is that there’s no control whatsoever over the output of the teams. They could not plan launch dates, campaigns for that product, nor could they give any valid projection on the project timing to their management.

In the following interviews with other stakeholders I’ve learned that there’s another issue connected to the delivery. Those were long planning meetings. They tend to last from a couple of hours to nearly a whole day, just to end with some number of tasks (user stories) scheduled for work, without any idea if this is feasible to be done in the next sprint.

Unpredictable delivery and long lasting and fluffy planning have come out as crucial issues to deal with.

Meet Our Client

The Challenges

Rolling Up Our Sleeves

Next step was analysis, to establish what was the cause of those problems. With some days to next planning I was observing the team, how they worked, how they picked up  the next item to work on, and how they communicated during the sprint. I also followed product people in performing their tasks.

What I’ve learned quickly was that there were no grooming or refinement sessions scheduled. In order to save time for the team, not to go to meetings, they didn’t have any preparatory meetings, but went straight to planning meetings directly.

Now, when the planning day arrived, everything went as I’ve expected. The teams were shown user stories that they will work on in the next sprint for the first time. This caused complete mess. Most of the first hour was spent to explain what was the intention with proposed user stories, why they were there, what is their essence – what they try to do for the users. With this cleared out they could continue to do the analysis of each user story, going into details of what was expected from each of them.

And finally, with this knowledge, they started compiling what would be a sprint backlog, or a list of things that will be done in the next sprint.

I was a bit surprised to learn that they didn’t estimate the complexity or the size of these user stories, so at first I thought that they don’t do estimations at all which is a practice some teams use. However, to my surprise those user stories have already been “estimated”. The estimations have been made by the product manager and the chief architect.

So, the two major issues had very clear causes:

• Long planning meetings were, at large there because no preparation for the meeting had been done at all;
• Volatility in delivery was there due at least two reasons, bad planning and meaningless estimation of the work to be done.

Another thing that I understood is that there was a serious lack of knowledge on the purpose and the way to perform planning so that it represents a meaningful, yet doable slice of a product in a relatively small amount of time. There were a few people in the team, now I’m talking about everyone involved in product creation, that had experience in how the planning should be done. However, they were a minority and they let the usual way of doing things in that company prevail.

When the Puzzle Pieces Fall into Place

So, we had to start from there - raising the level of understanding of everyone on board to the same level. 

Therefore, we organized the education of everyone who worked on that product. This assumed development teams & QA, product manager, system architect, designer. To be concrete, we had a one-day session called Agile Planning & Estimation, where we quickly went through basic concepts of Agile and Scrum. Then we focused on the purpose of estimation, different types of estimations, the purpose of planning in Agile, different time horizons, and concrete techniques used in a sprint planning. Inevitably, we went through sprint metrics and team velocity. In addition to this I held a one-hour session to get the management on board with the same topic.

Understanding the problem is crucial, education is necessary, but implementation of the solution is burdened with challenges.

In this particular case I was asked not only to do the education, but also help teams in setting up the process in the right way. What we did first was to introduce a refinement meeting. This was at first 2 hours slot per sprint, which we changed to 1 hour slot per week vert quickly. During this meeting the product manager who was in charge of the product worked on explaining the context, what are the goals, concrete user stories, and let the team touch upon the technical side of implementation in order to understand the complexity of the tasks.

When you put it like this it all sounds nice and neat, however, there were raised eyebrows, and even very vocal revolt against introducing another meeting where the developers will “sit and not do their job”. Apart from explaining that creating, let alone understanding the product is also their job, and that having people understand the why is essential for their engagement at their work, I also asked that we consider this as an experiment. We’ll introduce the refinement meeting for the next 4-6 sprints and observe what happens. With timeboxing this change it was easier for the organization to swallow.

Second thing that was introduced during the refinement was that developers estimate the complexity of tasks. From the initial interviews with stakeholders, I have found out that the reason why product manager and architect are estimating the work is because they didn’t believe the people will do their best to estimate the work, and that instead, they will put some buffers in estimation to assure that they have enough time. This is why I introduced estimations as an experimental, non-obligatory part of the planning. Developers did estimates, but we didn’t include them in the official reporting or as a base for predicting the project flow. I recorded and tracked them separately.

Outcome and learnings

Having a similar understanding of the planning purpose across the team, which was achieved through education, was quintessential for all further moves toward improving the work of those teams. Without it, it would be impossible to introduce changes as we would have complete misalignment of expectations and knowledge among team members.

As a final result of implementation what happened is that we spent in total 2 hours on refinements (which at some occasions became even shorter), plus one hour for planning, which is 3 hours in total per sprint. This was a serious improvement from at least 4 hours of discussions previously.

When you add the clear, meaningful sprint backlog where everyone is clear about why something is there and what is expected as a result, you get a massive improvement in the way of working, people’s engagement and focus.

With so-called “hidden” estimates that I’ve recorded and tracked I managed to show that over this time the team managed to do the estimation of tasks and achieve consistent throughput measured by the number of story points. With this, as an empirical proof, we introduced estimations given by the team as an official way of estimating the work to be done.

These things combined resulted in a stable rhythm with which the teams delivered their work.

In addition, engagement of all the people working on products literally skyrocketed, introducing new energy in everyday’ s work.

“Agile Serbia didn’t just fix our process; they revolutionized our entire approach to product development. Our teams are now more engaged, our delivery is consistent, and our business is thriving. It’s like night and day!”

Head of Product Development

If you are facing similar hurdles in your journey, contact us and let’s chat about how we can help and supercharge your team’s performance.