1 Backlog two scrum teams, 1 UserStory
Hello everyone,
I have a real-life doubt about how to use SCRUM in this situation:
- We have two scrum teams.
- We have one product owner.
- We have one backlog for all.
- Parallel 1 month's Sprints (2, one for each team)
Imagine that the first UserStory to implement (the one with highest priority) is CreateUser.
This task is in the system two big to develop for one team in a month, because it needs 50% of user-interface and 50% of service and backend development...
So the PO decide to break it on two. There's not longer "CreateUser" but two different UserStories:
- CreateUser user interface.
- CreateUser: service and backend.
each UserStory will be on a different SprintGoal and in a different AGILE Board.
or it's better having just one UserStory with two different definitions of done for each team?
Thanks in advance,
Split your big User-story in 2 or more smaller user-stories.
CreateUser : user interface + CreateUser : service and backend are not user-stories anymore but tasks on your sprintbacklog to perform in order to implement the inital user-story
I agree with Olivier, the User Story should not be decomposed by technology. User Stories or PBIs are intended to each deliver functionality of business value. A backend service does not provide business value directly to stakeholders.
If the story is too large for the development team to bring it to Done in a single sprint, then is does need to be decomposed into smaller stories, but not by tier.
Also, a User Story does not have a Definition of Done, the team has a DoD to determine if the work on a story is complete. Since both teams work on the same product,, the DoDs of the two teams shouldn't be different. If they are, they should at least have a common DoD around what it means for their increments to be integrated.
> This task is in the system two big to develop
> for one team in a month, because it needs
> 50% of user-interface and 50% of service and backend development...
Why would the ratio of work in technology layers make the story too big for one team in a Sprint?
A Development Team should have all of the skills needed, irrespective of the proportion of work across layers, to complete a user story.
I agree with the previous comments. Perhaps a different approach is in order?
From the end-user perspective, what is accomplished by Creating User?
Who has the authority to Create User?
What exception processing should there be around the Create User process?
Are there different methods/paths to create the user?
Are there different levels of user that can be created, with different authorizations/abilities?
Try and take the conversation away from the technical solution, and focus on what the business needs and the value that can be provided to them. You may be surprised not only by the depth of the conversation, but also the ease in which the "Create User" requirement can be broken down into many smaller yet still valuable parts.
are those teams cross-functional? Can team really deliver client need end-to-end? Because it sound it is not.
if there is one product - why not to combine teams effort and work in synchronized sprints, or even scale up to have one increment