Dear readers,
Today we published the second part of our interview series “Introducing the Plunet team”. Through these interviews you will get to know some of our colleagues and gain an insight into their tasks and responsibilities at Plunet. Today we spoke to Andreas, one of the software developers in our Würzburg office. Andreas will introduce us to the agile development method Scrum, tell us what Grooming is all about and give us an exclusive insight into the development work that goes into Plunet BusinessManager.
Happy reading and “Hello Andreas!”
First of all, introduce yourself. Who are you?
I’m Andreas and I’ve been working as a software developer in Plunet’s Würzburg office since 2009. I’m also the administrator for JIRA and the Scrum Master. I coordinate and moderate Scrum meetings, such as the Daily Scrums or Poker Planning, and I also deal with other smaller tasks.
What exactly is Scrum? Can you briefly explain it to us?
Scrum is an agile development method. This means that there are short release cycles, called “Sprints”, which take place over a defined period of time and during which a certain number of stories are implemented. In our case, each Sprint lasts for two weeks. Afterwards, we have the recap in the development team and the review. This is where the stories are presented. Then we start to plan the next cycle together with the Product Owner. During this time, we have a series of different meetings, which make up a significant part of Scrum. The most important meetings are Grooming before each Sprint, Poker Planning and the Daily Scrums.
What happens at these meetings?
During Grooming, the Product Owner presents his suggestions of which features or stories he would like to include in the next Sprint. The Product Owner generally represents the customer. Then we evaluate the suggestions to see whether or not they have been described sufficiently for the development. If all the information is there, the corresponding feature will be included in Poker Planning.
In Poker Planning, the complexity of each story is estimated by each participant. The assessment is made based on playing cards with numbers in the Fibonacci Sequence. Each participant holds up a card for each story. The higher the number, the more complex the story is estimated to be. As soon as the team has agreed on the complexity of each story, the meeting is over. On this basis, we can plan the time required for the stories and the next Sprint.
And then there are the Daily Scrums...
Exactly. The Daily Scrums are daily stand-up meetings. They usually last a maximum of 15 minutes. We use these meetings to discuss and inform each other about the development progress. These meetings also have a specific format: they take place standing up and a ball is passed around counterclockwise. Only the person holding the ball is allowed to speak.
That sounds a bit “Waldorf School”...
Maybe so. But this type of meeting has some key advantages. Firstly, the development team has the chance to regularly reflect on its progress so far. Secondly, if we run into challenges, we can create synergies for solving them together. Furthermore, according to Scrum teaching, the unusual format and the change of location and position stimulates different brain waves, which means that you return to work after the meeting feeling fresher and able to concentrate better.
What other advantages are there?
With Scrum, you have very short and manageable releases, which means that bug monitoring works very well. In other words, no prototypes are presented for comparison, but rather complete partial features that were created in a short development period. They may still contain bugs, but they are not complex modules that have been worked on for six months and involve very high costs for bug fixing.
Why did Plunet start using Scrum?
It was a request from the development team. We weren’t satisfied with the methods we were using at the time. In the past, each developer took a story and worked on it. Thanks to Scrum and what is known as the Product Backlog, we are now able to reach a general agreement with a clearly structured prioritization of all current and future features. This means that the development team knows exactly what is being processed at any time and what will come next.
What is the Product Backlog?
The Product Backlog is the complete list of all product requirements that we want to dynamically enhance. Requirements are prioritized from “very important” to “very unimportant”. The top part of the list is included in the Sprints. After each Sprint, the Product Backlog is resorted. Depending on the complexity, this means that the next ten to 20 stories in the list will be included in the next Sprint. We may even have as many as 60 stories in each cycle, as we usually carry out three Sprints in parallel.
How do you decide which stories have priority?
We have a points system with the following criteria: Is this feature important for our roadmap? How quickly does this adjustment need to be made for a specific customer? How many customers want this feature? If a lot of customers have requested a feature, then it becomes more important, of course. Do we urgently need this feature for our data integrity? The prioritization is determined by external and internal factors.
Is it always possible to take every customer into consideration in a Sprint?
Our overall delivery reliability has improved since we started using Scrum. We can now deliver features to our customers more punctually and reliably than ever before. However, it’s not always easy to incorporate every customer request immediately. For example, if customers urgently need certain features or customizations in order to go live, then this has priority in our Sprint planning. However, we always try to process the requests from all of our customers as quickly as possible.
Is there a fixed number of stories processed in each Sprint?
No, there’s no fixed number of stories. The complexity of the different stories is what determines the number in each Sprint.
How do you guarantee the ideal number of stories per Sprint?
It’s based on empirical values. We’ve developed our own system for this, which helps us to precisely determine the ideal number. Essentially, it is the delta of the estimated number of development hours and resource availability in hours. When these values match, the Sprint is full.
How long does a Sprint usually last?
It varies. At the beginning, we had four-week Sprints, which was pretty high. Now we have two-week Sprints.
Why did you shorten the cycle from four to two weeks?
There were a number of reasons. For one thing, the meetings were very long and time consuming; Poker Planning over four weeks can be quite tough if you have to sit in a meeting for three hours and evaluate various stories. The concentration suffers and you just end up raising the same card every time. That’s why we scaled down the Poker Planning meetings and shortened the Sprints. You can also be much more flexible with shorter Sprints in terms of planning and you can react better if there is a change in requirements.
