Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

User story and DoD

Last post 01:49 pm July 12, 2018 by Curtis Slough
6 replies
02:05 pm May 6, 2018


Let's imagine that I am developing an application and the first story of the sprint is to develop a DSL for this application.
Does the installation of the DSL plugin necessary for development think that it should be part of the DoD of the story?

09:39 pm May 8, 2018

Is the development of the DSL something that has value to the end-user/customer?

There really isn't much to go on since there's so little detail in your scenario, but the first thing that jumped out at me was the technical nature of the story in question.   Is it sliced vertically (layer, component-based), as opposed to horizontally (something that is customer-facing)?

12:25 am May 9, 2018

To be clear, definition of "Done" (DoD) applies to the product Increment, not the Product Backlog item (aka user story).  A Product Backlog item may have acceptance or test criteria which proves completeness when "done", but a Product  Backlog item does not have a definition of "Done" in Scrum.

You should look into emergent architecture, and ensure that you deliver at least one business feature of value alongside the architecture.  Don't build it if you don't need it - and you won't know if you don't deliver some business value.

01:12 am May 9, 2018

As Chris states, DoD applies to the increment, not the Product Backlog.

If the DSL is required to make the product DONE you could make a User Story for it, or it may be assumed as part of another story (how much effort/value?). It sounds like, based on your description: "develop a DSL for this application." you may want a user story for it (does it deliver value?), but those user stories are a little different to create when you are developing a dependent object. It could be the Give/When/Then Format. 

Given [my dependent application], when it needs [nature of or rationale of the dependency], then [what you need it to do, why do you need to create the DSL].

I think there are a few other formats for that type of dependency that may even work better. But ultimately, we would probably need more information to give you a more concrete answer. 

12:35 pm July 12, 2018

I don't agree that the DoD can't apply to the Product Backlog Item (PBI).  

Quoting from the scrum guide directly "When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means.".  

If following good INVEST practice where the PBI is independent and adds value in it's own right, the PBI and the increment are one and the same.  High performing teams will be producing many increments per sprint. 

Of course, acceptance criteria is unique to the PBI.  However, an overarching DoD covering more generic expectations applicable to all PBIs, ie, Unit Tests Successful, Acceptance Tests Successful, Deployed to xxx environment etc, is needed to ensure transparency over the real state of items in the sprint backlog as well as giving the team clear guidance over expectations of effort involved when planning the sprint.

The problem of applying a DoD just to the increment (assuming one increment at the end of the sprint) is that it can backload quality assurance to end of the sprint and a create a greatly increased risk of not delivering a shippable increment. 

01:42 pm July 12, 2018

Is the term “DSL” well known here?

Is it a common language?

Is it the only one user story for the Sprint?

What is its value for customer/end user?

01:49 pm July 12, 2018

+1 for Steven.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.