A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Some problems with relation to the criterion of ‘Done’ in a Scrum project

Done is one of the key parameters in a Scrum project. During a Sprint cycle, features need to be marked as Done at the end of the project, and this Done is something that identifies that these features are done for the sake of the project. However, there are problems when it comes to the implementation of this concept of Done. So, it is critical that the team has come to an agreement about what Done means, and this agreement is something that is correct. In a very simple manner, the team members should be able to say that the feature is actually done, when they actually mark the feature as Done (this statement is a bit confusing, but if you read it through from the perspective of a team member, then it would make sense). At the same time, in any discussion with fellow Scrum Masters, this definition of what done means is something that ends up in a lot of debate, once you get down to the actual details and when you involved the Scrum team member opinions as well. So, if you want to look at whether you have a simple definition of Done, here are some points for the same:
– All the development for the feature or User Story has been done.
– The testing team has done their testing and they are fine with the level of quality in the feature (which means that the defect cycle for the feature would have concluded).
– The Product Owner is fine with the quality level of the feature and their expectations of the feature has been done.
– The documentation related to the feature have been done, in terms of the artifacts that have been defined for the feature (such as the Design documents, the testing documents, and a similar set of documents that the team has agreed should be part of done). For example, this would mean that something such as coding standards that the team would have agreed upon as part of done are done, the same with testing documents such as Unit testing, System testing, etc.
– The feature has been integrated with the installer or release environment and there are no issues with this integration.
– In some cases, the definition of done could vary from feature to feature, depending on whether it is applicable. A document such as a User Design compatibility document would only be applicable at done for features that relate to some sort of Visual elements. A feature dealing with database integration would not have the need for such a standard to have been met.
– In many cases, teams decide to go up the value chain for their definition of Done, such as having a set of Release Notes for a feature which would incorporate changes, some assumptions and constraints in the feature, etc. If the team has decided to set such items as part of their definition of Done, then these would need to be added to the Checklist.
And that brings us to the concept of the Checklist, where a team should ensure that the criteria that has been decided for the definition of Done should be set out in a checklist in a form that team members understand, and then refer to this list while marking a feature as Done.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>