Having a good Definition of Done (DoD) might be one of the most important technical asset of a Scrum team. This makes the difference between delivering at the end of the sprint fully completed business features or half-baked software. In his blog post “Changing the Definition of Done”, Ken Rubin discusses the situation where a Scrum team might want to change an existing Definition of Done.
The Scrum approach recommends to deliver software incrementally in small iterations. This seems to be always an issue with activities that require a global view on the developed application like the software architecture or the user interface. In this blog post, Aviva Rosenstein, who manages user research for Salesforce, shares here experience about integrating user experience (UX) design into the Scrum development process.
The Definition of Done is an agreement between the Scrum team and the product owner on a minimum quality barrier for the product that’s being built. Establishing a minimum quality barrier has much wider implications than just better quality product, although that is one outcome of having a Definition of Done. This article is about the impact of a definition of done on the types of contract that Agile teams work with.
In this article, Faisal Mahmood discusses seven reasons why a Scrum team cannot get to done at the end of a sprint. In Scrum, “done” is often defined as producing a potentially shippable product.
In his article “Creating an ATDD Ready Sprint Backlog in Scrum“, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.
This article discusses the the role of the Product Owner in moving a backlog item to done. It explores how to achieve the productivity benefits of an up-front enabling specification, given the reality that Scrum is an empirical framework in which emergent understanding of the story under development is inherent.
This blog post contains an interesting grid that help you analyze every aspect of your scrum project if you want to declare a sprint “done”.