They were split into two parts: theoretical presentation and simulation SCRUM game. SIENN helps its employees to improve themselves and spread knowledge inside the company by organizing workshops. We exactly understand that the biggest value are people, who are experts for our Clients. One of the goals of the workshops was to answer the question:
‘How to work with Product Backlog Items to implement maximum value?’
Of course, there are two sides; devs who produce product and Client, who as a Product Owner, needs to be prepared to answer all the devs’ questions and understands requirements and their priorities.
I decided to talk about it because there are a lot of discussion regarding the topic if Definition of Ready (DoR) is really needed. In my opinion, it is a good practice to have DoR, and I am not the only person who sees the high value of DoR. Last year, at the Scrum Day Conference, SCRUM practitioners have been asked – how would they improve SCRUM, and they said: we should add DoR. Definition of Ready (or Readiness) is an artefact, which establishes the way that all team members in Scrum teams understand how a PBI should look like.
The presentation defined what is the most valuable requirements’ information, and when, and how we can get it according to team meetings with PO. It also focused on what questions can be asked. I gave a lot of answers for various questions, for example:
- What is the range of specific requirements’ pieces possible to choose, while PBIs are being build?
- What can we demand from PO before we decide to take PBIs to Sprint Backlog?
- Are there any unnecessary questions?
After we consolidated knowledge about Requirements in particular PBIs by defining DoR, we made one step further, and located it in Refining Process. Established Definition of Ready gave the possibility to understand what we could miss and what was needed to add PBI to the sprint. Thanks to this, we finally had an answer about what should be the sense of Refinement, and that sometimes ready PBIs were not enough. The conclusion was that PBIs should include only one User Story and focus on one particular functionality defined as working software.
During simulation SCRUM game we had to develop washing machine using clay, crayons, color paper or posi-its. We divided our group into small dev teams and started working on development. The hardness stems from the fact that every development team had just a piece of requirements, while all the pieces formed one full PBI. The teams had possibility to cooperate, but they did not! Even if it was said that they could talk to different teams and it was not a contest, they were competing during whole game!
Thanks to the workshops we all had the opportunity to understand how much value we get, when PBIs are complete and well described. We understood that requirements can have various forms like: User Stories, use cases, won’ts, action descriptions or mockups. Diversity of ways, how requirements can be described, showed us that every dev team and their PO can establish their own PBIs template because this is a specific decision of each team. There is no strict template, it always has to be discussed by a team and I think that’s why DoR is not a concrete SCRUM artefact.
It was a pleasure to work with you SIENN team!
