How to set up workflow for sprint planning?

🙋 Questions
,
1

We are trying to do scrum :slight_smile:
Our stories are written by me as a user-facing story, from the requirement perspective. That means that probably more than one person will work on the story to get things done.
We also use JIRA in our process to manage tickets and boards to monitor the progress.
Tickets are estimated in Story Points and they are estimated as a whole effort complexity to get the story done.
During the sprint planning session, we need to somehow plan the work for the next sprint.
These questions I have are operative and sure how to do it with this setup, so I am asking the community, based on your experience or opinion to provide feedback.

To whom to assign the story? Since multiple people will work on it?
How do I know how many story points to take into the sprint?

If I count SP per person to be like 13 SP, 10 developers all available with full capacity, so that would mean 130 SP we can take then how do I see this in JIRA?
Ticket is not only for one person.

We could create subtasks and assign them to a person but then subtasks will not have SP so I still would not see how many is on the person.
Or do you put into the sprint SP based on the velocity chart in JIRA, let’s say the average of the last 3 sprints so it doesn’t matter how many SPs per person is there?

Also, what about spillover tickets? Do you lower down story points and what point?

What I am asking is for feedback on the workflow how do you do it? If you could describe your process and address some of my questions here.

I hope I can get some valuable insight into other processes that could help us to try out some of those and figure out what to do.

3 Likes
2

Frist things first: Do you work as product owner or scrum master? Or as something else?
When the latter is the case my advice is directed to the persons being the named roles.

We use most times the first people starting working on the story, but we don’t use this information.

Learning how much your team is capable of. It will need multiple sprints.
Also don’t fixate on story points. They are simplification of way more complex things. Look for the content.

How do you come up with that? Technically yes.
But the team should say what they think is doable within the sprint.

We use subtasks and assign them to persons (maybe you wanna read why I prefer test subtasks over a test column).
But SPs are equally to time periods people working on something. Don’t go this way.

That is basically what we do. Or more precise: It is the base the team starts with assessing how much it is capable of. But it depends on the stories as well as an vacations and other stuff to do.

Our PO calculates our daily velocity like this (from previous sprints): working days of all people in the sprint X (sum of day of all people) / story points = story points done on average per day
For new sprints he then counts the working days of the team and multiplies it with the value above. This gives a rough value on what we are capable of. Rule of thumb.
Every then and now it turns out that thinks are either more or less demanding than estimated and that we are either have to pull new stories or keep some unfinished or untouched.

But really don’t look to much on the numbers. The are made up by gut feelings, they are not in any way scientifically created. Counting time would be.
Train the teams gut feeling what they think they are capable of.
And don’t turn it Scrum into small waterfalls. The team gets done what they get done. Estimates are … just estimates. Not 100% perfect predictions.
Don’t judge the team if the get less or more done. (Hell, was I demotivated once, when the team I was in was judged for not finishing all stories they pulled).

It depends on the already finished part. We lower the point for mostly finished stories.

Apart from that was another which helped us much to stay away from the 3 questions in the Daily. And using Walking The Board instead.
A video explaining it visually: https://www.youtube.com/watch?v=316qdj10j9M
Something to read with more context: Walking the Board on Daily Scrum. Scrum and Kanban can live happily ever… | by Maria Chec | Serious Scrum | Medium

And to add this: The Scrum Guide says nothing about story points nor user stories. They common pattern, but not mandatory.
Also they dropped the 3 Questions pattern. Do your Daily in the way how it helps your team.
To add on this: Our stories … aren’t real user stories anymore. Our product is so complex, we had to cut backlog items so small that they are more of technical tasks, to still be able to get them done in one sprint and have some flexibility.

1 Like
3

Thanks for your feedback :slight_smile:
Can you please give an example of this, I didn’t quite understand the formula.

3 Likes
4

A few things from my perspective.

  1. Make sure the stories are in the smallest viable chunks. It sounds more like you are doing mini-epics. If you are always dividing the work, it sounds like you have room to make smaller stories.
  2. If you are truly embracing scrum, you should not be assigning the work. You should be assigning the priority, but the team should determine the best way to get the work done.
  3. Be careful about getting too stuck on story points. They are estimates based on knowledge at the time and typically should not be repointed once the story begins. Any additional scope could become its own story. Avoiding scope creep is a challenge, but worth it.
    When you say you are trying to do scrum, did you have any scrum training? At our company, we had everyone participate in scrum master training when we first rolled it out to try and get everyone on the same page.
2 Likes