Kickoff internally

A kickoff session is essential to help familiarize all involved parties with the objectives of the project, the backlog, and the process. We facilitate an internal and a client kickoff before starting work on a project.

The internal kickoff is a meeting just for the Devbridge working team—design, product, and engineering. It generally lasts two hours or more and requires alignment inside the team around the objectives and backlog.

Prioritize the team’s shared understanding of the problem, including the roles of each team member, the key components of the platform, and the assumptions made in the estimate. On a cross-functional team, each member should have awareness of all decisions, regardless of discipline. Consider the impact of any outcomes or findings on the client kickoff.

Establishing definition of ready

The definition of ready (DoR) is used to create a shared understanding of what it means for a story or task to be “ready” to enter a sprint. This influences the way the product manager writes stories, negotiates them with the stakeholders, and plans the work.

DoR may vary from team to team, and exceptions can and will be made on a project. Determine this definition at the beginning of the project. Periodically revisit the DoR throughout the life of the project to decide if it requires any adjustments. If necessary, add requirements to address a specific concern, or remove some as the team gets used to working together.

DoR for backlog items

• a short summary
• a clearly articulated business value
• clear and testable acceptance criteria
• approved designs attached to front-end stories
• test cases and sample data
• identifiable performance criteria (where appropriate)
• link blockers and dependencies
• an estimate

DoR for sprint:

• all stories within sprint meet definition of ready
• all sprint items prioritized
• items small enough to fit in one sprint
• no hidden work in the sprint
• all blockers removed
• sprint items demonstrated to the client
• team review of all sprint items
• team member capacity calculations for the sprint
• agreed-upon sprint scope

Establishing a definition of done

The definition of done (DoD) is a way to quantify the completion of a story in a given sprint. User stories that do not pass the agreed-upon DoD should not be accepted by the product manager at the end of the sprint and roll over to the next sprint.

The best practices for the definition of ready listed above also apply to the DoD, in addition to the following:

DoD for design:

• designer review and approval of UI implementation
• meeting accessibility requirements, if applicable

DoD for code:

• no application build errors
• peer review of code (or produced with pair programming)
• check in and run code against the current version in source control
• code meeting style guide standards
• code alignment with client-specified development standards (OWASP, WCAG, etc.)

DoD for tests:

• unit test write up and passing testing
• integration test write up and passing testing
• supported device/browser user interface test write up (BDD tests) and passing testing
• meeting code coverage requirements

DoD for user story:

• meeting all user story acceptance criteria
• demonstration and acceptance of the user story by the product manager

DoD for sprint:

• successful client demo of user stories
• client acceptance of the user stories

Allocating full teams only

Starting a project partially staffed introduces challenges that cannot be completely remedied by later overstaffing. While this should be treated on a case-by-case basis, the squad lead and the managing director need to determine the minimum required team members for the team to start the first sprint.

Here are some risks to keep in mind:

• A partially staffed team is not effective at reestimating.
• Team members who come on board later lack the contextual project information built up during the initial stages (workshop, kickoff, review).
• The delivery timeline suffers when Sprint 0 and Sprint 1 are run at partial velocity.

For the record, I know this doesn’t work out every single time. As we grow and our accounts expand, there will be plenty of instances where we’re strapped for new colleagues to join teams in full sprint. Knowing you will have to remedy, consider recording and potentially rerunning a microkickoff session when new members join.