Some good discussion in the team meeting this morning. Let me try to summarize my responses on list. (see below) Thanks, L
On Jun 26, 2012, at 1:40 PM, Lance Speelmon <[email protected]> wrote: > In Atlanta, we started discussing the need for a Definition of Done (DoD) as > it relates to our sprint planning improvements. Here is a high quality link > to a short article that introduces the concept further: > > http://www.scrumalliance.org/articles/106-definition-of-done-a-reference > > I suggest that we start with a relatively conservative DoD to begin with and > then add to it over time as part of our ongoing reflection and process > improvements. To get the discussion started, I will propose that this might > be the right level of DoD to begin with: > > Code complete > Unit tests written and executed on every build > Automated functional tests > Performance tested (if applicable) > Meets release criteria / quality level for release May need some more investigation, but in short might translate into: no open blockers or critical issues; major, minor, or trivial are not desirable but are acceptable to ship. > Documented (just enough) > Product owner approval Ideally agile puts the team doing the work as close as possible to the customer. Before we can call something done, we should be asking the customer if the solution developed actually solves the problem expressed. i.e. if we did not solve the customer's need, how can we call it done? :) This should naturally lead to a healthy discussion about who the customer is and how we interact with them, but for now I expressed it simply as the SCRUM role "product owner". We should be careful not to set our sights so high with the DoD that we fail out of the gate. :) > > I believe this is pretty close to to established practices with the addition > of automated functional tests. IMHO, I would like to advocate for the > inclusion of the automated functional tests as they a) support the "no new > debt" tenant, plus b) will allow for increased velocity over time as we will > be able to make changes more rapidly while ensuring we have not regressed > existing capabilities. WDYT? > > Thanks, L >
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
