This article is the continuation of The Daily Stand-up Checklist for ScrumMasters, part II. The aim of this series of articles is to help Scrum Masters to prepare better for daily stand-up so it is efficient, productive and engaging. These tips are based on our observation of 100+ agile teams in their agile transformations.
Agreements
To get things working fast, regularly, and often in a self-organized team, Agile is based on the agreements of all people involved in the product development.
The self-organized agile team without a manager behaves must based on agreed rules.
ScrumMaster hence has to be sure if agreements and team rules are applied constantly. If not, maybe they should be discussed, challenged, or forgotten.
Definition of Ready
The first such typical rule is Definition of Ready. It is a checklist that must be fulfilled so your product owner knows when the user story or other backlog item is ready for the team to be planned, estimated, and developed. Definition of Ready significantly helps prepare requirements in more detail thoroughly. The benefit will be requirements done fast without necessary additional fix rounds.
An example of Definition of Ready being prepared for different backlog item types
Another nice setup for the preparation of DoR is suggested by David Koontz.
ScrumDesk team doesn’t start developing user stories if it is not recognized by the team as ready. If it is not ready, the product owner mandatory has to remove such backlog items from the sprint backlog. The reason is simple, we do not want to develop waste that might be changed very early because of a sudden change of opinion of the product owner. Therefore in ScrumDesk team members can mark a user story as ready.
The team can mark user stories in the sprint backlog as ready with one click
Definition of Done
The other part of the product development is a question of when the requirement is really done. Agile teams have an agreement called Definition of Done which is the checklist of activities that we want to follow during the development of the product.
An example of the Definition of Done:
- a requirement to be analyzed,
- developed,
- code reviewed,
- unit tests are written as well,
- documentation is updated,
- a code is merged into trunk,
- regression tests are green,
- the results are published in the preproduction stage,
- the results are accepted by the product owner.
This list might contain also non-functional attributes like quality, speed, etc. Definition of Done should be checked in the sprint planning and review sessions.
In ScrumDesk such Definition of Done is implemented as User Story Template where you can specify subtask types for all new user stories. That way you will keep your sprint backlog and development approach consistently.
To prepare a Definition of Done, ScrumMaster might arrange a workshop where people can express their opinion in a form similar to the picture below. All such cards are then sorted, filtered, and grouped to identify similar ideas and to define the agreement about the Definition of Done.
How to prepare Definition of Done in the workshop
There might be many Definitions of Done either per backlog item type or per sprint, release, or production.
ScrumMaster is just the reminder to the team to check if all necessary parts of DoD have been applied.
Not all parts make sense in all cases.
Make violations transparent!
Except for those two definitions, teams have very often additional agreements, i.e. how many subtasks can be in progress (Work In Progress limit).
The team should be aware that rules were broken. Scrum Master should make that situation transparent. Very often by the visual indicator on the Kanban board. After the retrospective team might agree on some change of rules and such flag on Kanban board can be very helpful in the building of a discipline.
Scrum Masters should observe the system, the work, and the team from end to end perspective. To see the whole value stream. With that in mind, new agreements might become necessary to introduce, some of them will not be applicable anymore, many of them will be necessary to update.
The next part will be about the preparation of ScrumMaster to know the status of people and the company.
