This is how you hit the ball out of the park in your first Sprint

Every Sprint, the Development Team is responsible for building a “releasable” Product Increment. The Product Owner may choose to release it or may not choose to release the Increment at the end of the Sprint.  Scrum does not prescribe a release frequency (i.e. PBIs can be released multiple, times a day, once a Sprint, once after multiple Sprints), but, at minimum, the Product Increment should be releasable at the end of the Sprint.

Though individual Product Backlog Items can have a “Definition of Done” (this is different from Acceptance Criteria), at minimum, the Scrum Team should have a Definition of Done for the Increment.  The Definition of Done promotes a shared understanding between the Product Owner, Scrum Master, Development Team and stakeholders on what it means when something is called as “Done”.  Through this, it creates “Transparency” for the Product Increment.  And when there is more transparency, better decisions can be made (by PO, management) to optimize value and control risk.

The practical challenge with this is that most organizations struggle to get anything “releasable” in the first few Sprints.  Current mindset, organizational debt, technical debt, functional silos and a poor or less than perfect Definition of Done are some of the contributing factors. In this blog, we will focus on Definition of Done

Who is responsible for crafting the Definition of Done?

Scrum Guide says

If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”.

The initial Definition of Done crafted by the  Development Team(s) is also constrained by the current skill set of the Development Team (e.g. They might not have automated testing skills and may only consider manual testing).  When the current Definition of Done is less than perfect, it leads to problems

1. The resulting increment  (especially when multiple Development Teams are working on it) may not be “releasable”, thereby  leading to “undone” work and reducing transparency
2. The Increment might accumulate “technical debt” and the cost of change and total cost of ownership of the product might increase
3. As the Development Teams improve their Definition of Done later, more work will be uncovered in the past Increments, which needs to be done retroactively

   • Scrum Guide : As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments.

   • Example:  Assume that the Development Team does not know how to write automated unit tests using JUnit and do Continuous Integration. Every Sprint, say, they are delivering 5 PBIs.  After 10 Sprints, they would have delivered 50 PBIs (technically, they would have delivered less as manual testing would consume more time). After the 10th Sprint, say, they decide to include automated Unit Test with JUnit and do Continuous Integration. Now they have to go and write automated unit tests for the 50 features they have delivered in the past.  This not only makes the work tedious, but may be boring, error prone and also slows down the Development Team in terms of delivering value in the subsequent Sprints.  Had the Development Team taken some time to learn these missing skills before their first Sprint, they would not have to encounter this situation.
4. Underlying organizations dysfunctions will not be addressed. Example – the organization might continue having functional silos with component teams (instead of cross-functional end-to-end customer centric feature teams) 
5. Lack of specific skills will not be explicitly recognized and there may not be a plan in place to fix it.  Example – pre-Scrum, a vendor may be responsible for doing performance testing.  When performance testing is not included in the Definition of Done, a plan to upskill Development Team members to learn performance testing might be missed
6. With legacy systems where good XP practices (like TDD, Refactoring, Continuous Integration, etc) are not followed, it becomes a lot more challenging to sustain Scrum adoption. The initial benefits that may be gained by adoption Scrum will be lost very soon.
7. When teams/organizations take time to get to a perfect Definition of Done before their first Sprint, it may uncover other risks that may get in the way of value delivery. You are better off identifying them before you start your Sprints to make it successful.

So What can you do to get to a Perfect Definition of Done before the first Sprint?

1. Identify gaps between possible current Definition of Done and the perfect Definition of Done
2. Take time to help Development Team members learn new skills/learn about different components that they are not familiar with
   • Arrange for XP technical coaching if necessary.  Learning how to do TDD requires a different type of thinking and it takes time.
   • Practice mob-programming where other team members not familiar with specific skills/area of the product are learning those. Example: One of the past clients that I worked with had their lead engineer travel from Texas to New York for 3 weeks to help others learn certain components for which he had the expertise.

Note: This is not Sprint-Zero. There is no such thing as Sprint Zero. In organizations, usually, there is a transition time between “let’s do Scrum” to “actually doing Scrum”. I am suggesting these steps during the transition time (and this should not be labeled as Sprint Zero)

It may take 2- 3 months sometimes to upskill team members and to get to better starting place. But it is worth it.

The very first Sprint should hit the ball out of the park. So it is worth spending time to get to PERFECT DoD before your first Sprint !!