Capacity Driven Sprint Planning

Question

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?

Answer 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.

Answer 2

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.

Answer 3

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)