Showing posts with label #done. Show all posts
Showing posts with label #done. Show all posts

Thursday, July 2, 2015

Definition of Ready (DoR) - "Aha! we get it feeling"

I am trying to make my teams root strong and in the process, I am questioning them about the purpose of each and every agile ritual or document they have. I strongly believe the need of understanding the purpose before starting to do it.

Today was the turn for DoR and Board Work Flow. During my preparation I compiled few points from various blogs and thoughts of sharing with you all.

Purpose of DoR:

  • It helps to keep the backlog items actionable
  • It gives the opportunity to team understand the value of backlog items vs. working on junk stories
  • Avoids wastage of time of both when a story is started and after a few days' work (if more information is needed to complete the story, the work on it stops).
  • Reduces requirements churn in development.
  • it makes sure team builds what is required
  • It expose inherent weaknesses of the system.
  • The Product Owner and Delivery Team work at different cadences. They focus on different things at different times. This checklist initiates the necessary discussion between Product Owner and the rest of the team.

What DoR should contain : 

  • What:  Is the goal or end-result of the story clearly defined?  i.e., is the expected behaviour or coverage goal as clear an unambiguous as possible at this stage of development?
  • How: Have you considered how to build the feature?  It doesn’t have to be much, but some thought about how to build and integrate the product story into the existing working product.
  • Who / Resources:  Are all the necessary resources (i.e., people, tools, IT infrastructure) available and committed to the product story to have a reasonable chance of completing within a reasonable amount of time?
  •  The DoR checklist is a living document and should be kept up-to date with the learning. 


I know my team gets very furious at times when they don't see a fully prepared story but I always insist them to work with POs to complete it.  In my opinion stories does not need to be 100% defined with all acceptance criteria. But it should be READY ENOUGH so that team can work on it without waiting in between. It should always be made 100% ready together with during grooming or similar kind sessions.

Board flow discussion was super exciting and would share the outcome in next blog.

until then!
Manisha

Monday, June 8, 2015

DoD : does it really help continuous delivery?

Short Answer: Yes if done right :).

Long Answer:
We are trying to come with DoD (Definition of Done) for my teams. We came up with our DoD, which is pretty much taking care of entire 9 yard, from code to validation.  It has checks for 
  • meeting acceptance criteria
  • making sure we are doing code review
  • release check list 
  • making sure automated test in written for code
  • architectural review
  • .....
This set looks almost identical with my previous teams (may be with 10-20% variance).  After the entire exercise, I am honestly challenging myself on how much DoD would help my team in delivery? Does anybody really cares for DoD in real day-to-day work? 

I thought of gathering some understanding on the true purpose and scope of DoD. For Teams who are doing continuous deployment and development, how is this artifact relevant? 
  • Is it a reminder for us to do our engineering job i,e commit your code, write acceptance criteria or automated test cases
  • we need DoD to have one understanding of Done
  • Use to DoD to get Story Points in the same iteration vs. next
  • Is it a big checklist for us to remember our mistakes
  • It helps teams to be more disciplined
  • Improves teams credibility amongst stakeholders
  • it helps team find weakness in the system
  • It reduces the risk of misunderstanding as well as the communication gaps between the teams and stakeholders.
  • it is something else. 
Relevancy is dependent upon the context you are in... Here are some tips which worked very nice for our team in past: 
  • Automate as many check as possible 
  • Don't let it collect dust. it is not static document.
  • Break checks across all columns vs. doing it at the end.
  • Try making your DoR big, so only right stuff can entire the work pipeline. And try to keep DoD short and concise.  
Again, until DoD is part of daily ritual, I doubt, it would bring the desired result. For DoD to allow us to focus on delivery, it has to be part of our daily routine/discipline

Hope it helps
Manisha