PART 2: Scrum at Davinci

In my first blog, I explained how we got to agile and how it changed our thinking. Now, I will tell you how we do agile development.

In Part 1 of my blog, I explained how we got to agile and how it changed our thinking. In Part 2, I will tell you how we do agile development. I decided to describe tooling which helps us in a separate article, because it deserves it.


Before I start, I will present those who are not very familiar with the Agile/SCRUM terminology with a short vocabulary (


Product Backlog

Prioritized list of tasks to complete the product. It is the sole responsibility of the product owner to prioritize the product backlog.


An iteration of work during which an increment of product functionality is delivered.

Sprint Backlog

Defines the work for a sprint, represented by the set of tasks that must be completed within a sprint. Sprint backlog is created from the Product backlog items.

Scrum Roles

There are three essential roles in any Scrum project: Product Owner, Scrum Master, Team

Product Owner Role

A single person with the final authority representing the customer's interest in backlog prioritization and requirements questions.


Team is autonomous and self-organized group of cross-functional individuals (software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc.). Recommend Scrum team size is max. 9 team members.

Scrum Master Role

The Scrum Master is a facilitator for the team and product owner. He/she makes sure that the methodology is followed and he takes care that any impediments are removed.




A picture which describes the process:


So let’s dive in.

The four key ceremonies of the agile development are the planning session, daily scrums, demo and retro session.


Planning session

What it is:

At planning, the whole team, including the product owner is present and they together agree what will be delivered in the next iteration (sprint).


How we do it:

Team, together with the Product Owner, negotiate the scope of the next sprint. They define a sprint goal and create the sprint backlog, out of the issues at the top of the product backlog. Sprint backlog issues are estimated by time. We switched from story point estimation of the sprint backlog to the time estimation, because it gave us possibility to plan better. Once, there is a mutual understanding and agreement on chosen issues, team commits to the delivery and the sprint is started. We work in two-week iterations, what means, that in two-weeks time we have to develop, test and present the functionalities agreed on the planning session. Planning meeting is time-boxed to max. 2 hours. To find out how is it possible, that the planning takes only 2 hours, read further the Backlog refinement section.


Daily scrum meetings

What it is:

A regular daily status meetings of whole team, planned for fixed times and strictly timeboxed.


How we do it:

The whole team meets every day for 15 minutes (usually before noon). The team members, one by one, shortly, but descriptively tell to the others what they did, how it went and what are they planning to do. In general, there is no space to discuss details of specific issues, and these discussions are carried out after the daily scrum as needed.

It is a good practice to start the daily scrum with looking at the burn down chart. If we are not doing well, we see immediately, that the line does not go gradually down. There can be few reasons for that like either someone forgot to fill in the remaining estimate, or we have a problem of some kind. If there is an emerging real problem, we can take immediate actions (special meeting with architect/analyst/experts, join brains, add extra resources, adjust sprint backlog, early damage control like prepare customer for possible delivery problem, etc.). If we are doing well, the line goes nicely down to zero. If there is a time left it’s up to the team, and the Product owner, how they want to use the remaining time (add new tasks, spend time on quality assurance or documentation, work on improvements, etc.)


Demo session

What it is:

It is the most important part of the sprint, where the team shows the delivery, proving to the customer that they fulfilled, what they committed to, during the planning.


How we do it:

The demo is prepared by the whole team. Everybody from the team prepares what she/he worked on and presents it. There is a dedicated time to prepare the demo and we put a lot of effort into it, to make sure that the demo is perfect and absolutely smooth. Demo is attended by the whole team, product owner, scrum master and ideally also by the stakeholders. The demo takes about 2 hours. This is the time, where we can see either smiling or unhappy faces, and where we can build up trust, which is the key success factor in the agile methodology.
Sometimes, in order to keep the demo interesting for all audience groups, we split demo into functional part, where we present the business functionalities and more technical part, creating a space for business people to leave after the first part, not to be bored by the technicalities.


Retrospective session

What it is:

The Retrospective session is a very important space for the team, where they can in a safe atmosphere, address issues, which dragged them down and create actions, which help them to deliver in the next sprint more functionality in better quality and with more joy.


How we do it:

Usually, immediately after the demo session, there is the retrospective meeting, where we discuss ideas, tips and lessons learned together with the client feedback. We time box it to 2 hours. In past, we did not pay much attention to retrospective meetings. It was just another meeting at which we spoke a lot, complained about the same things all over again, but there was a little what it was giving us in order to improve. We couldn’t get a good grip on this for quite some time. So we looked back and learn. It’s important that it is a safe place for the developers. It’s not about blaming someone, that we did not manage to deliver sprint, because of her/him, but summarizing what we learnt and how it can help us to avoid similar problems in the future.
Last but not least, it is very important that a retrospective session backlog is maintained. On each retro session, each team member adds one or two items, identifying what was the biggest impediment for her/him in the current sprint, holding down the individual or the team performance and velocity. This backlog is usually maintained by the scrum master.
In order to move forward, to improve the team and the velocity, few items (one or two) are transformed to concrete actions and assigned to people. This way, it is easy to track the progress on the next retro session and evaluate if the actions brought the expected result. 
Don’t try to change too much in one cycle, because it would end up either in a chaos, or just a complaining loop without any hope for improvement.

Then the next sprint comes starting with the planning session and it all goes over again until the successful end of a project.

There is one more very important meeting, which helps us to keep the wheels turning. Without this planning of the sprint would be an endless nightmare causing late start of a sprints, bad deliveries and break of the entire process.


Product Backlog refinement:

What it is:

At the product backlog refinement meetings, the team members either individually, or in groups review tasks at the top of the product backlog and make sure that they are clear and that they contain all what is necessary to resolve them. This is done during the actual sprint for the next sprint.


How we do it:

In order to have effective planning session, which can be time boxed into 2 hours, issues have to be thoroughly prepared. As the product backlog issues are constantly prioritized by the PO, team uses time of the current sprint to fully understand, break down and prepare issues on the top of the product backlog. This gives us enough time to challenge issues, request additional information or specifications, organize special meetings, etc. Issue shouldn’t take longer than 2 days to implement, if not, it is broken into smaller tasks. Team is trying to understand what are specific issues about. They can break a task to multiple tasks or subtasks if needed, they can address questions to the product owner/architect/analyst/etc. If a clarification is needed, they can request additional specifications or special meetings, etc. The scrum master has to make sure that this is done during every sprint.


This is how we do it.


In the next part, I will talk about the tooling, which helps us and how to avoid its evil nature …  


Publikované: 16. sep 2015 13:03 | Počet prečítaní: 2318
  • Peter Kobes

    CTO / Software Architect

    Peťo je náš Chief Technology Officer. V softvérovej oblasti pracuje od čias, keď sa veľkosť programov merala na bajty. V Davinci sa stará o to, aby softvér, ktorý robíme a to, ako ho robíme, robilo šťastným nielen zákazníka, ale aj všetkých developerov. Má rád nové veci a rôzne gadgets. Cení si netradičné pohľady na (obyčajné) veci a nemá rád slová "nedá sa".

We want you

Do you see yourself working with us? Check out our vacancies. Is your ideal vacancy not in the list? Please send an open application. We are interested in new talents, both young and experienced.

Join us

Podobné články