![]() ![]() If the answer is “no,” or, “I’m not sure,” then they may need to split them down, have more conversations about what they mean, specify some examples, etc. A team following that advice only needs to ask “Could 6-10 of these fit in a sprint?” If the answer is “yes,” those items are ready. ![]() One bit of advice we often share is that items should be small enough that 6-10 of them would fit in a sprint. On a team where the Product Owner is a collaborative, trusted team member, a Definition of Ready might be something as simple as, “We understand the items at the top of the Product Backlog well enough to decide if they would fit in a Sprint.” In its best form, a Definition of Ready helps a team have the right conversations during Product Backlog Refinement so that the Sprint Planning meeting is fast and effective. It focuses heavily on written documentation and formalized checklists. In its worst form, a Definition of Ready overlays a detailed stage-gate process on what is intended to be a lightweight, collaborative approach. But what about a Definition of Ready, a working agreement to align on what backlog refinement needs to be complete before the team pulls work into a Sprint? Whether you need one or not probably depends on two questions: “is the Product Owner a trusted collaborator?” and “is the work complex or complicated?” Scrum specifies that teams should have a Definition of Done, a working agreement to clarify what “working software” means for them. So, how do you know if you need a Definition of Ready? And if you do need one, how do you ensure it’s a tool for healthy collaboration? Two Questions ![]() A Definition of Ready can be a useful working agreement for a Scrum team or it can be a step away from healthy, dynamic collaboration back into the world of too much process. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |