Ever tried “elegant” Sprint 0?

I used to think that was there any elegant way to spin up a new team and sail towards the Agile way of delivery. And finally, I managed to understand that the “elegancy” piece won't come from any books, but it iron outs from lessons and mistakes learned from our experience.

Who wants to be a code monkey?

One of the important lessons learned was about the concept of “Sprint 0” which encouraged me to write this article. Again as you would have heard a lot of analogy on Sprint 0 by this time, what I would closely like to compare sprint is to a vehicle; like it or not as it heavily depends on how you initially treat the vehicle, decides the life of your vehicle. Similarly, if you didn't have a good start or proper preparations for your team, trust me you are going to be super busy solving issues one by one.

Let's start quickly — make it very simple and clear.

Goal

The goal of a Sprint Zero is to deliver some usable value that can be built upon by the next team. Like a Scrum Sprint, the goal of a Sprint 0 is to be productive, but a Sprint 0 is not required to do as much any intensive software development as a Scrum Sprint.

The main benefit of a Sprint 0 is that it allows a team to get an idea of the work ahead of them. They can then self-organize in order to perform better in the long run. This also builds confidence in team members that they can handle the work to come. When individuals go into a project without clarity, they are likely to become slow at some point which could affect the success of a Sprint. Sprint 0 seeks to avoid this obstacle by offering an opportunity to plan a framework for success and ensure a working Sprint environment.

List of Activities in Sprint 0

• Accounts and permissions for the new team members for starting involving in the project
• Agree and document “Agile Way of Working” for the squad
• Groom/Refine Sprint 1 stories
• Baseline story points using affinity estimation.
• Define/Review JIRA Workflow for tickets
• Define, Agree and document template for creating different types of tickets in JIRA
• Define, Agree and Document the CI/CD flow
• Define, Agree and Document the environments needed for the project
• Define, Agree and setup the local environment setup
• Define, Agree and Document release/version strategy
• Define, Agree and Document GIT Branching strategy
• KT/Handover and Document on the Technology Stack of the project and do a handover.
• Agree and document Manual/Automation Testing Strategy
• Define and document “Definition of Done”
• Define and document “Definition of Ready”
• Agree on Stakeholders

Define — “Definition of Ready”

Having a Definition of Ready means that stories must be immediately actionable. It’s therefore clear that a User Story has to meet a set of minimum criteria before it’s ready for inclusion in the work of the next sprint. This set of minimum criteria is the Definition of Ready as stated below.

• The ticket should fulfill all INVEST criteria (The invest criteria’s are mentioned below this section)
• The ticket should be story pointed.
• The ticket should be unassigned.
• Each ticket should have the subtasks created if any.
• The ticket needs to have gone through refinements with the team, as well as with the Product Manager/Business Analyst.
• Acceptance Criteria should be clearly defined, summarized and agreed on by the team after refinement.
• The ticket should have all assumptions and dependencies documented and linked in JIRA.
• The ticket should have UI attachments, and all related documents and links if needed.
• The ticket should have the API contracts defined if needed.
• The ticket should have the labels, epic, sprint, fix target version if needed.
• The ticket should have all roadblocks clarified and removed.
• The ticket should follow the template based on the type of ticket.

INVEST Criteria

• Independent — Stories within a Sprint (and preferably within the backlog) should be independent of one another. We should be able to deliver each Story on its own, regardless of the state of the other Stories.
• Negotiable — We don’t expect each Story to be a contract, but rather the essence of new functionality that can evolve based on learnings during development.
• Valuable — Each Story must deliver value to the customer, i.e. slice Stories vertically through the software stack, rather than horizontally when necessary.
• Estimable — We don’t need to be precise, but we should be able to put a Story Point estimate against any well-formed Story.
• Small — As a rough guide, we should be aiming for Stories <= 10% of the team’s Sprint capacity, i.e. if we have an established velocity of 100 Story Points per Sprint, we shouldn’t be taking Stories estimated at > 10 Story points (or 8, if we’re using Fibonacci numbers for estimation) into the Sprint. We should be splitting them during Backlog Maintenance.
• Testable — We must be able to verify that the functionality we deliver meets the needs of the customer before delivery, therefore exhaustive testable Acceptance Criteria are important.

Define — “Definition of Done”

A “Definition of Done” drives the quality of work and is used to assess when a User Story has been considered as really completed. In order to consider the ticket as “Done”, the below criteria should be met as follow.

• All the acceptance criteria have met the work done for the tickets.
• All the subtasks for the ticket should be assigned and completed
• All development work should be code reviewed by a minimum of 2 team members.
• All development work should include unit testing, following a TDD approach.
• Each feature developed should be in a new feature branch in a version control system.
• All the codes should be pushed into the version control and build using CI / CD tools (must be deployable without any human intervention, if something breaks the provisioning script, the team should be accountable to update it)
• The feature branch should be merged to master branch and smoke testing should be passed in the development environment by the developers
• The feature should be tested manual/automated in the staging environment before deploying into the production environment
• All the features developed for the sprint should pass the regression testing and verified by testers in the release environment.
• Features developed should be reviewed and accepted by the Product Team
• When the ticket fulfills all criteria above, the JIRA status should be moved to “Ready to Release”.

Additional Information [Updating features from “Ready to Release” to “Done”]

• Each feature released should be approved by the Product team.
• Each feature approved by the Product Team should be successfully deployed into the Production Environment.
• Each feature delivered should pass all smoke tests in the Production Environment.
• When the ticket fulfills all criteria above, the JIRA status should be moved to “Done”.

Finally, once you have managed to get these to be fulfilled, you are very much good to start your real works. Following this practice, I trust you won’t really need to turn back with your screwdrivers to fix the boat!

Wishing you all the very best!