You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I am solving the same problem as in the original assignment. I have a scrum team of, for example, 6 members. the team's weekly sprint and velocity is, for example, 20 story points. How to easily plan capacity according to individual team members in JIRA, ideally directly on the "Active sprints" board. If I said, for example, that 2 team members will be absent 2 days out of 5 in total. I will have an average number of storypoints per team member per day. Can this be solved through some function in JIRA? That I would see when planning? How many story points are planned versus how many story points the team has capacity for? Thank you :)
I would like to ask a wider question? Why do you want to do this? This is actually against the agile manifesto and what story points are really supposed to be for. Story points are really supposed to be tracked based on the team level, not the individual level. And teams are supposed to have a shared velocity in which they are able to commit to a certain number of points with the goal of hitting a certain target amount not equivalent to 100% of committed to. Even the best teams only hit 85% of their planned work. So what are you actually trying to accomplish because if you are trying to do story point tracking on an individual basis, more than likely story points are not the right thing for your team.
Hi @Marian Hlaváček -- Welcome to the Atlassian Community!
Yes, and...to Clark's answer:
How does your team do sprint planning and use people's availability to plan today?
An alternative to what you suggest is for the team to pause at the start of planning to quickly identify who is present/not present during the sprint. That conversation will act as a reminder of who is available to help and the impact on the team's ability to deliver value. Together they can adjust their goal and the work identified to meet that goal before the sprint starts. And later at the retrospective, the team can use that information to evaluate how things went and how to experiment toward better in the future.
You're right, story points are for the team velocity estimation, not for individuals. I was hoping that if we could scale team speed in story points if a team member is not available for a given sprint, it could help the team plan how much they can realistically accomplish in a sprint.
Previously, in MS Azure DevOps, we used a combination of Story Points on the User Story and hours on the Tasks (smaller parts of the user story). But this can lead to the fact that we convert Story points into hours, which goes against the meaning of story points. At the moment, we will try to estimate only story points on User stories in JIRA, and if the given sprint is not 100% team capacity, then it will be up to the team how they decide the work.