Planning capacity using story points

What method of estimation and capacity planning are you using today? Why do you believe that switching from that method to story pointing is a step that will be beneficial?

Problems like this are why I tend to steer teams away from story points. Although relative estimates may be good for very large bodies of work to help figure out how to invest time in discovery and refinement, there are a lot of problems with them once you have well-refined Product Backlog Items and are looking at capacity planning.

Lets say we have 5 members in the devt team, 1 of the members is at 70-30 (70% for prod support then 30% for sprint items, so if he has 65h in the sprint, only 19.5h worth of story estimates can be assigned to him)

What you've described isn't really a team, so there's little context for team-based estimation. You've got at least one person in a silo, apparently doing work assigned to them by others, and with marginal need for teamwork.

How do we handle this when we move to story points? How do we ensure that one resource has 70% of his capacity allocated to something else?

Treating someone as a resource with capacity to be ensured is unlikely to get the best out of people. My advice is to raise everyone's game, especially regarding quality. Build a team that self-organizes around work they pull to them, recognizing that "support" for a product may imply technical debt and the need to improve the Definition of Done. The team will then be able to frame joint commitments they can estimate for and meet.

I have said this in response to quite a few questions about planning.  

Stop trying to plan a Sprint that provides 8 hours of work a day for each member of the team.  Plan a Sprint that will deliver a valuable increment of work for the stakeholders.  Let the Developers pull work from the Product Backlog that will support a Sprint Goal that was crafted to ensure a valuable increment is produced.  There can be work done in a Sprint that does not support the Sprint Goal but the focus of the team is to meet that goal and anything distracting them should be avoided.  

If they know that there will be significant amount of production support then they can take that into account when they plan their Sprint.  Just as they would take into account some lack of ability if someone on the team is taking vacation. It isn't about planning work to take up all of a person's available time. It is about planning work that will benefit the stakeholders and provide opportunities to gain empirical knowledge to influence future work. 

A second thing I would like to comment on is this statement that you made.

so if he has 65h in the sprint, only 19.5h worth of story estimates can be assigned to him

I take that to imply that at Sprint Planning your team assigns every item in the Sprint Backlog to a single individual to complete.  Why not let the individual Developers pull work from the not started list of items as they have time available?  That can lead to better cooperation and more knowledge shared across the team.  This is possible if you do not plan a Sprint to have 8 hours a day of work for each individual.  

In addition to what others have notes, I'll share this:

• What empirical evidence do you have that shows you support is 70% of a person? What will the person do if 100% is needed for support, will they stop working on the Sprint Goal?
• Multi-tasking will have an impact on productivity. Instead of getting a 70-30 split from a person, it will be less due to context switching. And it burns people out.
• Forget about planning a Sprint at 100% capacity. In complexity it won't be perfect, and you'll need to leave some buffer. Knowledge workers need time to think, this isn't the industrial revolution where factory workers are being managed.

What method of estimation and capacity planning are you using today? Why do you believe that switching from that method to story pointing is a step that will be beneficial?

The way the team used to do it is we had a capacity planner in an excel sheet where everything is computed, recurring meeting hours, day-offs, team holidays, 10% buffers, etc. And for each dev/qa listed there, there would be a resulting 'Available hours'. We then add stories/bugs on that same sheet with their hourly estimates and then it would automatically deduct from the 'Available hours' value for each resource. Sprint planning then ends once 'Available hours' is 0 or near empty. 

I find this a bit tedious and most often (if not always), they always underestimate their tasks. Thats why I thought of switching to story pointing as it would be more accurate in terms of planning since we will base the amount of work from their actual velocity

....they always underestimate their tasks.

What makes you think that they will be able to better estimate by using Story Points?  An estimate is still an estimate, no matter what words you use or the basis by which you estimate.  

And if I read between the lines, it sounds like you are going to change the Excel sheet to start using Story Points instead of available hours.  So you are going to track how many Story Points each person "completes" during a Sprint. I assume that every individual will estimate their own stories. This can become a problem as it encourages people to overestimate so that they "look good" because they have a higher velocity than others.  

The premise of Story Points is that the entire team estimates each item, arriving at a consensus that will be used.  That is the purpose of Story Poker.  

As I said before the word "estimate" is not in the current revision of the Sprint Guide.  The word "size" appears only twice.  This the single statement that has any relation to the effort.

The Developers who will be doing the work are responsible for the sizing. 

That could be taken to mean that each developer sizes their own work.  And in all honesty that is ok since the teams are self-organizing, self-managing.  So if they choose to operate in this manner, no one can say they are wrong.  

I still stand by my original statement. Stop trying to plan a Sprint that provides 8 hours of work a day for each member of the team.  Plan a Sprint that will deliver a valuable increment of work for the stakeholders.

Hi,

As mentioned above, there is 70 % of support work and 30% sprint work.

Assumption - The support work may or may not increase per person in a timebox event.

My few cents -

1. it seem slot of support work, and support work may/may not be unplanned. Can we try Kanban in this situation.

As Kanban is meant to have change management and service delivery effectively .

2. As an recommendation capacity should not be equal to load of the team. For better team health and for long run of project -

     a) team members need time to learn and update themselves for new technologies, about projects to apply them            in their day to day work.

     b) Team members need room for innovation

     c) better ideas will come when team members upgrades themselves

     d) Teams mental health will be better

3) Recommended size of a user story is 1/6 to 1/10 of a sprint duration. So 30% of a resource utilization might not be suffice for completion of user story according to definition of done as per organization/team's guidelines.

Try pull based Kanban system to deliver user story's based on current team's capacity each day.

May be we can try working as 3 team members for support task ( on rotation basis per sprint in case Scrum following is recommended by organization), and 1 team member for dev task(on rotation per sprint - can change in next sprint)

and 1 person can work on support or dev task on need basis , based on DSU status.

Using a capacity sheet in general is useful as if half of the team is not available (e.g because of holidays) then the outcome is probably lower and you have to think about that in the planning.

I see the advance of story points/t-shirt sizes or whatever, that you are able to break up the "hour mindset" within a company. 

I assume from your post, that there is still a "what can we affort" mindset, thinking about the work load putting into the sprint. As I am currently facing a similar behaviour in a team, I try to transform the mindset to think about what can you get out of the sprint - (and it is not everything you put in) - 

It is more likely what is your sprint goal and what output can you archieve for it. Focus on that and I bet, your current problem gets resolved.