Tracking team member capacity using Stories > Sub-Tasks - Large team

Prologue: I apologize for the harshness of this response.  I have tried to rewrite it 5 times and when I try to make it "softer" it looses emphasis.  I have been faced with this situation many times and I'll admit it frustrates me to explain it.  So, please forgive the harshness and please focus on the message. 

My advice is to stop trying to find a way to do this.

project management and team leads are struggling to determine who on their team  has too much or too little work.

In Scrum and most of the other agile practices that I know are not concerned that everyone has work.  The concern is that the team of individuals know what work needs to be done to deliver the needed value and will self-organize to ensure that it is done. Focus on the team being able to consistently deliver usable increments of value and not on whether everyone has something assigned to them.  

We just want to make sure we have the devs accountable for the stories they have sub-tasks in but aren't  taking on too much/too little given the scope of the team. 

So you want to micromanage the developers?  Why not allow them the professional courtesy of letting them say that they will get work done and then trusting them to do it? You don't mention anyone that is fulfilling the responsibilities of the Scrum Master as defined in the Scrum Guide. That could be the reason that your organization is struggling with this.  The person fulfilling the Scrum Master responsibilities helps the organization understand the Scrum framework.  I suggest that you read the Scrum Guide, especially the sections for the Scrum Values, Scrum Team, and Scrum Artifacts. Maybe it will help you to better understand how the Scrum framework is focused on "team" and not "individuals".

The challenge i'm running into is: project management and team leads are struggling to determine who on their team  has too much or too little work.

I don't think it is. Your challenge is that you've got Jira but you don't have Scrum. Work is tracked, but value and quality are not as thoroughly accounted for.

If it's any consolation it's a widespread problem. In common with many organizations, you've layered a tool over existing management practices in which work is allocated and decisions are pushed. Self management and pull are short-changed. That's what's inhibiting agility and more productive empirical outcomes.

Thanks for the reply, Daniel, I understand the frustration and I hate that I'm writing this here at all. Maybe some more context...

I am doing my best to have SOME form of Scrum here... but our organization is very top-heavy and all the work is already defined for us by C and V level employees on what to do with a light expectation of when it's needed by. There is a lot of work expected from the team to be "done" in two week increments. I realize Scrum may not even be best for us, but then we get chastised from leadership for having no predicatability or ability to estimate.

With all that said...

In Scrum and most of the other agile practices that I know are not concerned that everyone has work.  The concern is that the team of individuals know what work needs to be done to deliver the needed value and will self-organize to ensure that it is done. Focus on the team being able to consistently deliver usable increments of value and not on whether everyone has something assigned to them.  

Yes, I agree, but because we have some a large team, we obviously don't want employees sitting around and doing nothing. If any of our leadership sees the employees not working on something THEY wanted in the sprint, it will be hell to pay. I, myself, am not concerned with individual output at all, but I'm just trying to set-up a way for team leads to be able to see something easily in Jira so that they know who they can delegate the needed work to. 

So you want to micromanage the developers?  Why not allow them the professional courtesy of letting them say that they will get work done and then trusting them to do it? You don't mention anyone that is fulfilling the responsibilities of the Scrum Master as defined in the Scrum Guide. That could be the reason that your organization is struggling with this.  The person fulfilling the Scrum Master responsibilities helps the organization understand the Scrum framework.  I suggest that you read the Scrum Guide, especially the sections for the Scrum Values, Scrum Team, and Scrum Artifacts. Maybe it will help you to better understand how the Scrum framework is focused on "team" and not "individuals".

This was admittedly a bit harsh - I am aware of the values, team and artifacts. Given the context, as you can tell, some of leadership wants to micromanage the devs. I want to protect them from this and let them be accountable, but some are too junior and will not step-up. I, myself, have been somewhat filling the role of Scrum Master, but it is not a role for product owner to have obviously. I have looked to help from team dev leads as Scrum Master but they do not want to and/or are also individual contributors. Project management also will not step up here. The dev team leads need some way to view who on their team is working on what to gauge their performance - and given the structure of our team and lack of ownership, we are struggling there, yes. So again, I am simply looking for a visualization of work planned/completed - not to say "you can take more work" or "you need less work" but to make sure the load is being shared by such a large team.  

Ian - thank you. You're not wrong. My last comment should shed some light on why we're running into this. It's becoming more clear that maybe Scrum is not the way for us, but I am unsure on how to best organize work for this team and provide leadership with the predictability they're looking for. 

I'd take it a step further than Daniel. Not only are the various agile methods, including Scrum, not concerned that everyone has work, ensuring that the team has enough slack is crucial. Consider that agile methods are built around responding to uncertainty and change and that one of the core principles is working in a sustainable pace. Having slack gives the team the ability to absorb changes such as a reduction in capacity or the discovery of additional work without having to have change control processes around deciding if the work should preempt planned work or not.

I would want to take several steps back and understand what the real problems are and then figure out what the root causes of those problems are. Why does anyone want to determine who on the team has too much or too little work? What would they do with this information? What are the real concerns with the team's ability to deliver value, Sprint over Sprint?

Basically the project you are managing is not Scrum. There is nothing wrong to use other methodology or framework to run your project, if it suits your organization, but please note that what you do has nothing to do with Scrum. At all.

@Brian, thanks for the clarification and understanding.  

I think that you are right that Scrum is not a good fit for your organization, especially given the top down push of work. The Scrum framework works best in situations where empirical discovery is required to shape the work that is needed.  In your case, it doesn't seem like empiricism is wanted. 

I understand and appreciate that you are trying to help the individual contributors.  If I were in your position, I would not try to find a single framework or practice and instead borrow from a bunch of them to create something that works for your situation.  But if there is a requirement, implied or stated, from the upper management that everyone have tasks assigned to them to represent everything that they are doing, you may be better off going with the old project planning GANTT chart. It works well for projects that are planned out to the minute details. Since you are already using Jira, you should look at their Roadmap feature. It is based upon GANTT charts and can give you similar functionality.

Every team is unique and may require different solutions to address their challenges. It's important to continuously inspect and adapt to ensure that the team is working effectively and efficiently towards their goals. I would suggest making some changes to the team workflow:

- Divide your team into two fully functional teams. Here are some potential drawbacks of having a large Scrum team:

1) Coordination challenges: As the number of team members increases, it can become more difficult to coordinate tasks and ensure that everyone is working effectively together. Communication overhead and miscommunication can become significant, leading to delays or misunderstandings.

2) Increased complexity: Larger teams often involve more complex interdependencies, which can make it harder to manage dependencies, prioritize work, and track progress. It can also make it harder to make changes or pivot in response to changing requirements or market conditions.

3) Lack of focus: With more team members, it can be harder to keep everyone aligned and focused on the same goals. People may have different priorities or interpretations of what needs to be done, which can lead to confusion and inefficiencies.

- Split your big stories too. It is generally recommended that stories be small enough, typically ranging from a few hours to a few days of work. The reason for this is that smaller stories are easier to estimate, track, and complete. They provide a more granular view of progress and allow the team to make more accurate forecasts for future sprints. This will solve the problem with subtasks.

- Instead of assigning stories to developers, it's recommended to give them the autonomy to pull stories from the sprint backlog. This means that developers are free to choose the stories they want to work on, based on their individual strengths, availability, and interests. 

By giving developers this freedom, they are more likely to take ownership of their work and feel empowered to contribute to the team's success. Additionally, this approach encourages collaboration and flexibility, as team members can work together to determine the best way to achieve the sprint goal. 

During daily Scrum meetings, the team can discuss the progress of each story and identify any potential roadblocks or issues that need to be addressed. If a developer has not pulled a story from the backlog and is not currently working on any other tasks, this can be discussed and addressed as needed. Overall, this approach helps to promote transparency, accountability, and collaboration within the development team.

but then we get chastised from leadership for having no predicatability or ability to estimate.

Over the course of multiple sprints, you can gather metrics on your team's performance in terms of story points. Using this data, you can then estimate the total scope of your project's stories and make predictions on when it will be completed. 

Thanks everyone. I was sort of afraid of these responses as being a slap in the face of reality. Was really hoping the organization could adapt to Scrum but it’s clearly not going to work. FDD might be the way to do but still have ways to go in terms of process. 
 

@Daniel I’ve used Jira roadmapping - could definitely help. I prefer ProductBoard but I suppose it becomes a useless tool when measuring feature value for prioritization and roadmapping when the value and priority are being predetermined be leadership :)  thanks again everyone

@Brian : I've been serving as a scrum master in large organization and large teams for quite some time now and do understand your pain and challenge. The management can force us to micromanage some members, especially contractors, to ensure they are getting bang for their buck. 

Please allow me to share my two cents here. As you would have now understood, sticking to Jira for visualizing capacity utilization is a challenge. Please don't spend any more time on it unless the product team can customize it for your purpose. Instead, why not use face to face team conversations or joint team calls to let the "suspect" make their work transparent. 

In my experience, the psychology around this practice actually works. I am sure, with your experience in people management, you can accurately infer who is being honest and who is blabbering BS, and inflating their work. You can validate the estimates and statuses during these team calls. I am sure you would have done it already, if not please try and see how it goes .

Thank you, @Harshavardhan. You're absolutely right, and I certainly am aware of who "suspects" are. However, this isn't really my concern for a few reasons:

• I'm not any of these members' direct managers. Any lack of effort, I could work with their team leads on. 
• Any of my inferences surrounding people's effort or lack thereof is shoved to the back of my mind, because while I am cognizant of it, I am not technically the Scrum Master, even though I'm lightly filling the role. I am, as others have suggested, more concerned with team velocity, quality, and iterative design than I am with individual output. 
• It's not so much that we have a lack of input from some ICs; there are some that are stronger than others, of course. I'm simply being asked by the team leads to help them gather this info for them, even though I stress how it is not about the individual. 

Either way, I really appreciate the feedback and shared sentiment here. The organization is just not ready, and maybe never will be, to adopt Scrum.