Sprint planning and JIRA
Hi,
This is my first time writing on this forum, please forgive me if I make mistakes :D
We have stories that are user-facing, meaning they describe business requirements. To get the story done we usually need multiple people from different stacks (Fronented Alokai - FE, Backend SAP CC - BE, and AEM - CMS + Testing). Story points reflect the complexity of the story as a whole - the whole effort to get it done. How to do effective planning on this type of setup? We had an issue with whom to assign the story. Who is a lead if it is cross-functional? We could write sub-tasks for each part that needs to be done (FE, BE, AEM) and assign those to people. But then we don't see how many story points each person has and how many loads they can take in the sprint.
What would be your approach to this? What would you do differently? Do you have a similar setup and if so how do you manage planning?
Any thoughts are appreciated.
Who is a lead if it is cross-functional? We could write sub-tasks for each part that needs to be done (FE, BE, AEM) and assign those to people. But then we don't see how many story points each person has and how many loads they can take in the sprint.
Think of it the other way around. If a team is truly cross functional, why would it need a lead, and why would a particular individual have any points at all? Why would work be assigned, when team members have the ability to pull work to them as and when capacity is available?
In Scrum, the only purpose of estimation is so the Developers can collectively get their arms around how much work they can take on in a Sprint, so a Sprint Goal is met and a Done Increment produced. Everything else reduces to value delivery and empirical process control. It's not about individuals sawing away at pieces of work.
We had an issue with whom to assign the story. Who is a lead if it is cross-functional?
The situation is that you do not have a truly cross functional team. Stories are shared accountability (irrespective of whom it is assigned to), and the teams need to be made aware of it. You could decide as a team who should the story be assigned to out of the roles you have mentioned. You may use tasks and subtasks to assign it to the different functions you mention.
But then we don't see how many story points each person has and how many loads they can take in the sprint.
Agree with the comment made by Ian, it would be wrong to track how many story points each person has (focus on value delivery rather than being story point accountants). Use story points only for estimation, to understand how much you can accomplish as a team in a sprint.
For tracking you may use the Burndown chart in Jira that will give a view of the progress and I encourage teams to look at this chart on a daily basis during the daily scrum.
Let me start by recommending you read this blog post (https://ronjeffries.com/articles/019-01ff/story-points/Index.html) by Ron Jeffries, who is considered the person that created story points. He explains the origins and some of the misuses of them.
A Scrum Team acts as a cross functional unit. The unit has the ability to do a variety of things. There could be parts of the unit that can accomplish things others can't. But that is something that the team works to rectify and not retain. If there are individuals with specialized skills, those individuals should work with others to help them learn how to do that work so that no one blocks or gates the team's ability to complete their goals.
Consider a sports team. Everyone on the team knows how to do everyone else's work. Some are better at specific things than others and they frequently do that work. However, if needed anyone on the team can step in and move the team towards the goal of winning the match. Consider a retail store. The entire staff is capable of checking a customer out at the cash register, stocking the shelves, unloading boxes from trucks in the back. Again, some can do it better than others but no one is incapable of helping in any position. And all of them are working together to accomplish the goal of selling product and creating happy customers that will return to buy again. Software development teams should not be any different if they want to be able to efficient and agile.
What would be your approach to this? What would you do differently?
I would coach the team to stop thinking of individual work and focus on what they can accomplish collectively. Help them understand that teamwork means everyone helps to accomplish the goals they set and everyone helps the other team members to become better. I'd encourage pair programming so that others can learn the silos. I'd recommend that they think more about what they can deliver that the stakeholders would find valuable and stop thinking about what they can deliver that makes each individual look good to their manager. I would also suggest that they stop using story points and consider using fruit and vegetables to estimate the work. Help them realize that the combined work is equal to the size of a single grape, lemon, orange, honeydew melon, watermelon, pumpkin (or whatever different sized fruits and vegetables they would like to use) and that they only have a single bowl (the Sprint) to hold the fruit. They can all eat parts of the food by slicing it up, but there is only so much food that can fit into the bowl. But discourage anyone from thinking "I can't eat that much fruit and vegetables". They need to think "we can eat all of those fruit and vegetables."