What does “done” mean in Agile?

The definition of “done” in Agile development methodologies is one that carries much importance with it. The development team needs to decide when to call a feature or a product “done”, or “shippable”. A product or feature ought to have been completely and thoroughly tested, and it should be accepted by the product owner. One might also argue that there should be some documentation, at least at a minimal level, to describe what certain elements of the software are for. The user story that a feature is designed to solve should be addressed in its entirety. There will nearly always be additional ideas in the minds of the programmers, ideas of features that can be improved upon or added. The important part of the definition of “done” is that it should be more dependent on addressing the user stories, as some things to a development team are never quite “done”. If a product is thoroughly coded and tested, proven to address each user story in its entirety, and accepted by the product owner, it is likely that the product fits most definitions of “done” and “shippable”. Since there are differing opinions on what truly defines “done”, there should be criteria established in advance. The criteria could possibly be defined on a per project basis, but it could suffice for a team and product owner to decide on these criteria for all of their common projects (Bavani, 2012).

Ready 2 Done

The task list for a product, which is essentially the backlog in Agile, should consist mostly of completed tasks when that product is said to be “done”. The tasks on the list are assigned different priorities and time estimations, that designate how important a task is to the product and how long it will take to complete a task. The tasks with mid to high level priorities and feasible time estimations should be complete, before the product is deemed “shippable”. Most of the lower priority items should be completed as well, though it stands to reason that there could be very low priority items that are not necessary to the current iteration of the product or feature, and that the product or feature could be considered “shippable” without having these items completed. There are also going to be items with time estimations that will simply take too long for the product owners requirements, and this is to be expected with most projects. A product or feature is “done” when the code is thoroughly tested, the user stories and priority backlog items are addressed, and the product or feature is accepted by the product owner (Chakravorty et al., 2014).


Works Cited:

Bavani, R. (2012). Distributed Agile, Agile Testing, and Technical Debt. IEEE Software, 29(6), 28-33. doi:10.1109/MS.2012.155                                                                                  http://ieeexplore.ieee.org.libaccess.sjlibrary.org/stamp/stamp.jsp?tp=&arnumber=6336723

Chakravorty, T. A., Chakraborty, S. B., Jigeesh, N. C.  (2014).Analysis of Agile testing attributes for faster time to Market: Context of Manufacturing sector related IT projects. Prodecia Economics and Finance, (11) 536-552.      http://acsjup.sjlibrary.org:9797/MuseSessionID=49eaca85778e02ed2c7e2ec5267d4/MuseHost=ac.els-cdn.com/MusePath/S2212567114002196/1-s2.0-S2212567114002196-main.pdf?_tid=83e172ce-528f-11e4-801e-00000aab0f27&acdnat=1413173887_3abf9077c5644b61f4232628b754cd80

First Picture Link:


Second Picture Link:



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s