Skip to main content

Small team and DoD

Last post 04:34 pm May 5, 2014 by Sukrut Wagh
10 replies
03:06 am April 18, 2014


We have a team of 2 developers, 1 QA, SM and PO = total 5 members. We have just started working on a new product and are trying to groom our backlog into releasable software every sprint. Somehow it is getting difficult for us to comply with DoD for every sprint. It looks like in one sprint we will mark all our items as Not Done and in next sprint Done because some of the DoD items were not completed in previous sprint. Second problem is we may not be able to demo every sprint.

Just to make it clear we have 4-5 teams working on the same product and has a really good DoD. All teams have enough experience on Scrum.

Cheers
Sanjay


09:40 am April 18, 2014

> We have just started working on a new product and are trying to groom
> our backlog into releasable software every sprint. Somehow it is getting
> difficult for us to comply with DoD for every sprint

If this is becoming a regular thing, it suggests you are inducting work into your Sprint Backlog that you know you are unlikely to complete in the available time-box.

So is backlog grooming and/or Sprint Planning in need of improvement here? You sound as though you suspect it.


12:48 pm April 18, 2014


I agree that we need improvements in grooming and planning however as a PO I would like to have something demoable and releaseable every sprint while Dev team says they cannot and will be working on DB part in this sprint and UI in next sprint.

Cheers
Sanjay


02:31 pm April 18, 2014

If the Development Team aren't delivering a potentially releasable increment to the Product Owner each sprint, then they simply aren't doing Scrum.

The Scrum Team (PO, Development Team, and Scrum Master) need to refine the Product Backlog into items that facilitate this incremental delivery, and to plan each sprint accordingly. The Scrum Master should be coaching the team to do this.


04:10 am April 19, 2014


Posted By Sanjay Saini on 18 Apr 2014 12:48 PM

I agree that we need improvements in grooming and planning however as a PO I would like to have something demoable and releaseable every sprint while Dev team says they cannot and will be working on DB part in this sprint and UI in next sprint.

Cheers
Sanjay



You may want to look at the following:
- Are they collaborating, or just handing tasks from one (DB) to another (UI)? Usually it takes time to learn collaboration.
- What is necessary to cut the Product Backlog Items smaller, so they can be delivered within a sprint?
- What is your sprint duration? You should prefer shorter durations, however they require good collaboration and automation, so if you're not there yet, you might think of a longer duration (max 4 weeks) in the meantime.


03:40 pm April 20, 2014

Dev team says they cannot and will be working on DB part in this sprint and UI in next sprint



This is seen commonly in teams developing apps using waterfall process. Many teams transitioning to Scrum face such challenges.

One of the approach we took under such circumstance was to create a PBI for DB schema designing/modelling (no implementation yet) & refine stories to group UI & DB layer implementation tasks.

It is very common that any DB related activities are not final & changes are required as the product features evolves.

Incremental approach to anything is useful. Whether its DB related, UI related or any other architectural aspects. Nothing is final. Things change :)

Regards,
Sukrut


05:31 am April 22, 2014

Is the team cross-functional? is the QA able to do some coding if that is what is needed. Can both the developers do the DB stuff or are you relying on people outside the scrum team?


12:19 am April 28, 2014


I won't agree to designing DB w/o implementation in one sprint and actual work in next sprint. I would go for a thin vertical slice every sprint.

Just to make it clear - team is good on Scrum but we are facing this problem as we are starting working on a new product with lot of unknowns. We are good on slicing things properly for the existing product.

Cheers
Sanjay


08:33 am April 28, 2014

> we are facing this problem as we are starting working on a new product with lot of
> unknowns. We are good on slicing things properly for the existing product.

That being the case, might it be worthwhile to reserve a significant portion of each sprint for spike work? This would help reduce the unknowns for each following sprint.


12:34 am May 2, 2014


Correct Ian, that's how we are progressing.

Cheers
Sanjay


04:34 pm May 5, 2014


Posted By Sanjay Saini on 28 Apr 2014 12:19 AM

I won't agree to designing DB w/o implementation in one sprint and actual work in next sprint. I would go for a thin vertical slice every sprint.




Agreed & that is what I meant, perhaps, lacked clarity.
"a PBI for DB schema designing/modelling (no implementation yet) & refine stories to group UI & DB layer implementation tasks."

DB layer implementation tasks here is the coding part. In your words, slice features & group activities pertaining to a feature (UI+DB design+Implementation) .

Thanks,
Sukrut


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.