Viewpoint posted on Nov 7, 2018
Behind the scenes on how we structure our work for KS
Structuring work while collaborating with different teams in a large company is important. In this blog post, we want to share insights on how we actually work, the Scrum framework, and how we deliver a product we’re proud of.
Read on to find out more from our Product Owner Medi about the way we implemented the Scrum framework, the corresponding meetings and how the development team manages to maintain its momentum:
What is a ‘Sprint’?
In order to get the development team aligned we work with the Scrum framework. This is an Agile framework enabling the development team to accomplish projects within a two-week cycle called a ‘Sprint’. The teams are self-managing which means there’s no hierarchy within the teams and they decide individually how they work. Together the teams work on a project in which they have equal responsibilities and saying. The Product Owner gets to prioritize the projects (‘Stories’) in the backlog and decides which story is next in line to work on. The Scrum master is the buffer between the team and the Product Owner and makes sure all team members can do their work in an Agile way.
Who is leading the Sprint?
The PO determines which stories make it to the backlog and in which timeframe they should be accomplished. The content is determined together with the different teams (Mobile, Front-end, Back-end, Mobile, QA and design). When an emergency occurs, for example when another story needs priority over the current one, the Scrum master determines whether to deviate from the planning. Together with the teams, the Scrum master decides which technologies are used to achieve the stories.
What is the reason behind the Sprint being a two-week cycle?
We initially started with a three-week cycle so we could comprehend unforeseen circumstances, but it turned out two weeks has a more compact scope in case of unexpected situations that force us to prioritize another story. If we would shorten the Sprint to a week the planning would be a mess: With a one-hour meeting per team, a weekly retrospective meeting and Sprint review meeting once a week, Sprint would be very inefficient and nearly impossible. A two-week Sprint works best for our team at this moment.
How do you decide on prioritizing stories?
During the Sprint planning meeting, we define a goal for the upcoming Sprint. The technical functionalities outwait the commercial belongings almost always. At the end of the day, our main concern is to deliver a high-quality product.
In what way is the upcoming Sprint announced to the team?
We do not announce the upcoming Sprints. During the Sprint planning meeting, the Sprint is defined. The Sprints are named after the week numbers so we can easily track what happened at that time. We are however very transparent in terms of sharing the product roadmap. Because we are with a relatively small team with a lot of different disciplines and just one PO it’s not necessary to announce a Sprint in the traditional way.
What happens if a story is bigger than two weeks can comprehend?
That is the beauty of Scrum: It’s such a flexible framework. We define how long a story takes by determining story points. If a story can’t find a passing because we underestimated the amount of work we prioritize which story is up next. The Sprint enables us to stay as close on the story as can be. The retrospective at the end of the two weeks gives us a chance to gain insightful feedback on the process: What made us lose momentum and why? Could we’ve done something to prevent this?
To plan and maintain the Sprint there are some necessary meetings that need to be executed:
Or as we like to call it the ’stand-up' is a meeting of maximum 15 minutes with the development- and Q A team to briefly go through the tasks of the day per person so we are all in sync of what we are working on. Fun fact: The stand-up can’t be executed sitting down to ensure the meeting will be as short and efficient as possible.
A frequently hosted Agile retrospective meeting will turn a group of individuals into an effective team. After the Sprint Review, we discuss how the two-week sprint process went during the Sprint retrospective: How can we make the previous two-week process more efficient or improve our work? How are we planning to do this?
Backlog, Prospects and Sprint Status:
The Scrum master, product owner and most important stakeholders discuss the status of the stories in the backlog. What is the status of the stories and how do we prioritize them are the main bullet points of this meeting.
Our Product Owner Medi is in charge of the Sprints backlog: All the projects that need to be accomplished in order of priority. In the planning meetings, the product owner defines the planning of the sprint together with the back-end, front-end, embedded, QA and mobile teams.
Thank you Medi, for explaining how the KS development team structures their work to deliver a product they are proud of.
Keep an eye on our company blog for more interesting observations on the way we work and the latest company news.