Small team and DoD
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
> 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.
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
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.
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.
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
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?
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
> 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.
Correct Ian, that's how we are progressing.
Cheers
Sanjay
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