How to factor in requirement analysis into sprint capacity
Hi. We have a couple of team members who are cross skilled and do some dev work abs testing but also act as subject matter experts and work with the business to clarify requirements to get stories sprintable. What is the best way to account for the requirement analysis work within sprint capacity?
We have thought about either adding stories that have a definition of done to assess the requirement and create a sprintable story or just having a placeholder story with a typical number of story points to keep capacity aside for this kind of work.
thanks.
Our team uses hourly capacity planning (I'm honestly not a fan) and each dev is set to 7 hours a day of productivity.
In our capacity calculator we've basically figured out the story point value per hour based on our dividing our velocity by the number of developers, and then it automatically calculates how many points a developer can take depending the total hours configured in the planner. When a developer has meetings, training, or other adhoc type work, we just reduce their hours on those days, which also reduces their story points.
Disclaimer: This is not ideal in my opinion. I'd much rather just burn down points rather than hours, but our team struggles with completing stories in succession and ends up closing them all in one big bang at the end of the sprint, so that option isn't available to us. Furthermore, story points and velocity are more of a team level metric and there could be pitfalls when trying to track it per developer. I don't think it's all that ideal, but it's what we have for now.
Another option would be like you said and make a story for it (I've seen teams have just general administrative type PBI's), point it and count it toward their velocity for the sprint.
What you describe as "requirement analysis" is what is referred to as Product Backlog Refinement in the Scrum Guide:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Previous iterations of the Scrum Guide suggested that about 10% of the Scrum Team's capacity would be reserved for refinement activities, but that suggestion was removed in the November 2020 revision. My understanding was that some teams were interpreting it as timebox. In reality, the true amount of refinement varies and is probably related to the current state of the Product Backlog. If the work that is ordered higher in the Product Backlog is well-refined and ready for inclusion in an upcoming Sprint, then you may need to spend less time refining than if the top of the Product Backlog is vague and not ready for work.
The Scrum Guide isn't prescriptive on how to go about carrying out refinement. Personally, I've seen it done in a lot of different ways. Some teams divide up the Product Backlog Items among the team members and carry out refinement as individuals, pairs, or small groups. Other teams make refinement a whole-team activity. There's really no wrong way to carry out refinement.
I would suggest cross-training the whole team on the work. The Product Owner should be the one who is working most closely with the stakeholders outside of the Scrum Team, but that doesn't mean that people on the team also can't interact with stakeholders. All of the Developers should be able to help out in refinement. If people are missing business and domain knowledge, work to develop that. They may not be "experts", but having domain knowledge will also help them to make better decisions when building the product and how to best go about testing it to find potential issues before external stakeholders do.
As far as how to go about tracking the work, it doesn't matter. I can't remember any team that I've worked with creating a story or story pointing the effort for refinement. Most of the teams look at the state of the Product Backlog in Sprint Planning and consider refinement when talking about how big the Sprint Goal should be or how much work to pull in. The output of refinement becomes visible in the improvements made to Product Backlog Items throughout the Sprint.
We have a couple of team members who are cross skilled and do some dev work abs testing but also act as subject matter experts and work with the business to clarify requirements to get stories sprintable.
Why only two? Aren't all those doing the work accountable for refining stories, so they are in a Ready state for Sprint Planning?
What is the best way to account for the requirement analysis work within sprint capacity?
By going on to provide valuable increments of usable quality. If the team are being held accountable for something else in regards to the refinement they do, ask why.
I think @Ian Mitchell nailed this one. And @Thomas Owens also is spot on the fact that this isn't something that you measure. Think about this and see if you can come up with your own answer.
The Sprint is used to build valuable increments that satisfy the Definition of Done and accomplish the Sprint Goal. So how would stories in the Sprint Backlog for refinement activities actually help accomplish building the increment mentioned? Wouldn't they be more accurately tied to future, unstated Sprint Goals?
Your question made me ask myself "What do they do to track 1:1 meetings with managers, lunch breaks, toilet breaks, getting something to drink, talking to someone about a reddit article they read recently, contributing to the fun Slack channels at work, providing feedback for someone else's annual review, checking your stock portfolio, Snapchatting with your friends, attending organizational 'All Hands' meetings, career development activities, ...". Because where do you draw the line on what needs to be tracked vs not?
Don't plan a Sprint based upon how many hours the Developers have to sit at a keyboard and type code. Plan it to deliver a specific collection of valuable work that the team feels comfortable they can achieve.