Wednesday, 24 February 2016

Ready making

Working with an unmanaged Jira instance brings a lot of chaos. While on one hand people working with Jira should be given the freedom to make their own workflows in an Agile environment, on the other hand this freedom stands in the way of creating a Continuous Delivery factory. Grinding through many instances of Jira I find a lot of similair differences. The most common anomaly are different statusses in workflows that are actually transitions. I want to elaborate on one in particular: the "Ready" status.

In a lot of Scrum projects I see people who make issues "Ready". The term "Ready" sounds strange to me, because it looks to me as making something ready to be picked up by a Scrum team is just the transition from a "New" issue to an "Open" issue. Is this a too short approach? Let's find out.

The process of making issues ready for development contains the following tasks:

  1. Dependencies; Is there other work to be completed before this issue can be solved?
  2. Skills; Is the team skilled enough for this task?
  3. Space; Is there room in the code to make the change, or do we need too much refactoring?
  4. Design.; Does the user story have design and workflow?
  5. Stakeholders; Who is involved in the user story and has a say (is he the Reporter)?
  6. Work ahead; are there any issues dependent on this one?
  7. Following work: are the recievers of this work ready to recieve it?
  8. Requirements: Functional and non-functional requirements are clear?
  9. Acceptance: Acceptance criterea are clear?
  10. Flows: Are the happy and bad flows defined?


To complete the above steps the refinement discipline in Scrum is the solution. All items with status "New" cannot be picked up before the refinement is done; refinement is the step in which issues are made ready. Refinement is not done in a Scrum event, it is a continous process between the Scrum master, Product owner, stakeholders and the team.

All items in the "Open" status ought to be groomed enough to be picked up, teams can define a threshold of quality for "Open" tickets; this is written down in a Definition of Ready. A DoR can be different for different teams.

Resources:

  1. http://leanmagazine.net/lean/make-ready-agile-projects/
  2. http://guide.agilealliance.org/guide/definition-of-ready.html
  3. http://www.allaboutagile.com/is-it-ready/
--
02-03-2016 Updated grooming to refining
Posted by at

2 comments:

  1. Unknown1 March 2016 at 10:09

    I think adding a DoR can be valuable, but I think the part on grooming is confusing for the point you're making, and besides that not correct. Refer to the Scrum Guide on the definition of refinement: "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog". Grooming is just the old terminology of what is now called refinement. Adding detail (what the DoR is about) should be done by the whole Scrum Team, and the Scrum Master does not necessarily need to take place in it. Please don't mistake the Scrum Master for a Key Developer or a Project Leader.

    ReplyDelete
  2. Unknown1 March 2016 at 11:40

    This is a very good blog on the subject: http://www.van-rooden.nl/blog/2016/02/24/product-backlog-refinement-explained-13/. Please note the sentence "The goal of Product Backlog refinement is to work with the Scrum Team and stakeholders (when relevant), to get Product Backlog items in a ‘ready state’". I also like the comment about why you shouldn't give a blueprint for a ready item.

    ReplyDelete

Subscribe to: Post Comments (Atom)