2

I have recently taken over as Scrum Master for a team.

I plan on implementing capacity driven sprint planning.

The challenge is, we have several User Stories (that should've been classified as Tasks IMO) that have carried over into multiple sprints.

Let's say I have 3 "User Stories" that each have spilled over into at least 3 continuous sprints due to their monolithic nature, vagueness of requirements, and inevitable expansion of work.

Would my first task be to get the PO and team together to slice up these types of User Stories during grooming?

It would seem that the first step in implementing capacity driven sprint planning would be to groom the backlog into items fitting the INVEST ideal, so that we can adequately fit items into the capacity.

Am I on the right track?

  • Why do you think these "monolithic" stories should have been classified as tasks? Tasks are always smaller than stories. – Llewellyn Feb 13 at 20:43
  • 1
    @Llewellyn, Simply by definition. The items don't provide direct user value, i.e. As DevOps, I'd like to add another server to help with load balancing, I have always classified as Tasks with sub-tasks if necessary. – Mark Saluta Feb 13 at 20:50
  • @MarkSaluta "As DevOps" is not even a story. DevOps want to be paid. That is their story. They can live a super happy life without load balancing. Don't write "As a horse I want to draw the cart to market" stories. The horse does not want that. Instead start writing "As a merchant" stories. – nvoigt Feb 14 at 11:40
  • 2
    @nvoigt Would you say then: As a user, I would like the product screen to load 50% faster, so that I can checkout quicker. A subtask of that could be to add another server to help with load balancing. That sound about right? – Mark Saluta Feb 14 at 18:29
  • Sure, that sounds good. – nvoigt Feb 14 at 18:43
1

I think you are on right track of breaking down the work items. Here is what you can do

Option 1: If user stories are based on "business need", do not split them further. But create meaningful tasks from team's inputs. Based on the availability of each team member, create tasks that are achievable within 1 sprint. Ensure the "Definition of Done" for tasks and user story is defined in grooming meetings in agreement with Product Owner.

Option 2: Create "Features" based on "business intent". Create sub user stories based on the "capacity" of the team. Every sprint team can size the user stories. Ensure that during grooming the team defines the criteria for "measuring the progress" of user story. For example, if team decides the user story size = 10points. Team agrees that every day they can make a progress of 0.5 point, then you can easily track the progress of work on daily basis.

Hope this helps.

1

Your approach is a good one.

Would my first task be to get the PO and team together to slice up these types of User Stories during grooming?

It would be worth spending some time coaching the team to understand why their stories need to be improved.

Also, as a Scrum Master I try and avoid saying things like:

"I plan on implementing capacity driven sprint planning."

"...my first task would be to get the PO and team together".

Instead I would say:

"I will be recommending to the team that they try capacity driven sprint planning"

"...my first task would be to recommend to the team that they get together and explain to them why it would be useful".

The tone a Scrum Master uses when addressing the team is important. It is a servant leader role rather than a management role.

  • 1
    Thank you for that. It is a great reminder and something to keep in mind every day. – Mark Saluta Feb 14 at 22:08
0

If they spilled over because requirements were too vague and the work expanded, then I'd say the team wasn't diligent enough in refining acceptance criteria.

I'd say to take them out of the sprint and move their status back to "approved" from wherever they are now (committed or ready or whatever). At that point have delivery team and stakeholders work together to see what can be eliminated in order to deliver something in one sprint, and nail down acceptance criteria. Maybe a story still goes beyond one sprint, but try to nail down acceptance criteria among all people involved so that:

  • Developers know what to do and can relay progress easily via tasks drawn from AC
  • Testers know what to test when it gets to them. You might be able to deploy to a test environment and say "hey, can you take a look, I think I have criteria 1, 2, and 3 done". It'll help dev and QA work together and give transparency of progress to the team

Be careful merely "slicing up." Whenever possible, ensure that a story delivers business value and isn't just part of something larger that has business value (to be delivered who knows when)

New contributor
MStodd is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.