From Continous Delivery to Continous Deployment

One of key definitions of the Scrum framework is “Definition of Done”(DoD).  In order to be able to decide when an activity from the Sprint Backlog is completed, the Definition of Done (DoD) is used.  This bring all the team members to the same level of understanding about the conditions when a task is completed. The definition of done for our team is as follows:

Any issue in the Sprint Backlog is considered to be “Done” if the analysis, development and validation stages have been completed successfully and the acceptance criteria has been met. The deployment is not a prerequisite for the issue to be considered as “Done”.


Okumaya devam et “From Continous Delivery to Continous Deployment”

How to handle a failed Sprint and how to avoid it ?

Let’s imagine a typical Sprint of 2 weeks duration. If the team is delivering software continuously since more than a year it means that the team had run around 26 Sprints past year. Do you think it is feasible that each and every Sprint has been finalized with success? Obviously, it is not surprising that a number of Sprints fail to accomplish the Sprint Goal. Well, even though it’s not the best scenario, a mature Scrum team is supposed to manage mentally and emotionally the consequences of a failed Sprint.

Every professional aims to be successful at personal level. Similarly, everybody enjoys  being part of a winning, successful team. Nevertheless, it is very likely that a Sprint could not achieve the targeted Sprint goal and fails due to several reasons such as bad planning, dependencies, challenging Sprint goals, changing scope etc.

Okumaya devam et “How to handle a failed Sprint and how to avoid it ?”

My favourite Scrum event: Sprint Retrospective

This week, 6th of February Tuesday was World Retrospective Day. I’m quoting from the website:

World Retrospective Day is a volunteer-based, globally coordinated effort to share in the power of retrospectives.

People from different countries around the globe organized and participacted in order to celebrate it.

That’s why I thought that it would be a good idea to write a down a blog post about how our team performs it, perhaps the most fruitful event of Scrum framework.

First of all, this is an entirely internal event lead by the Scrum Master closed to any stakeholders . Typically, we organize it just after the Sprint review scheduled for 2 hours (we run 2 weeks long Sprints). At the very beginning, we have a quick chat about the past Sprint followed by the D.A.K.I. session. DAKI is the abbreviation for:

  • Drop
  • Add
  • Keep
  • Improve

Here below you can see the output of our last Retro session.                                                            

Okumaya devam et “My favourite Scrum event: Sprint Retrospective”

Does a Scrum team meet more than enough?

One of the most common discussions regarding the Scrum Framework is if there are too many meetings within a Sprint ? Is this allowing enough time for the development team to work towards the Sprint Goal ?  Typically, there are 4 Scrum events defined at the Scrum Guide :

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective ( We call this simply as Retro :))

Let’s figure out the total number of hours spent on 4 events along the Sprint. We are running 2 weeks long Sprints and the scheduled events are taking 2 hours, 15 minutes/day, 1 hour and 2 hours respectively. Hence, the number of  hours spent during the event is 7,5 hours within a Sprint. Considering each work day as 8 hours, this refers to almost 10% of the total Sprint time. Depending on the characteristics of the team, this ratio may go up to 15%.

As you would agree spending 10% of the Sprint time for the Scrum events is feasible. In return, the team makes the wise planning driven by the priorities, come together everyday to get fully aligned, share and demonstrate Sprint results with the stakeholders and finally have the opportunity for self-inspection and identify improvement points. If none of these meeting had exist during the Sprint, the team would still need to organize meetings to discuss all the details and probably would spent much more time. In essence, running Scrum events in such a structed way is serving well to the productivity goal of the team among others.

Image Reference