Portfolio: Can I manage estimation and capacity just at the epic level?

[Michael Kelly]

There is a lot in Portfolio that looks good to me, but I really really don't want to get into the detail of estimating individual stories and team member availability and allocation on stories. I want to think of the team as a whole as a resource that has capacity and estimate at the level of epics. This means:

• estimates would only be on epics (not stories or sub-tasks)
• we would use team velocity to determine capacity and project delivery dates for sets of epics

Can this be done?

Thanks.

-michael

[Steven F Behnke]

Yes it can be done but if it's a software development team I doubt it will be effective. The reason Scrum teams use stories is because they can commit to chunks of work that are actually attainable within their iteration – If you aren't allowing them to estimate at that level and you aren't understanding capacity at that level you risk overrunning your deadlines and rougher estimates.

[Michael Kelly]

Thanks Steven. I appreciate your admonition to protect the team from unrealistic deadlines. But please rest assured that I have no intention of putting my team at risk in that way. I've now been building software for 24 years (14 of those using Agile). I'm fairly confident, at this point, in my ability to guide the team through the generation of "good-enough" high-level estimates. In fact, I would argue that investing only what's absolutely necessary to create good-enough estimates is a feature of being "agile" (i.e. "responsive to change").

If you will accept that I will do no harm with this knowledge, maybe we can discuss how it might be done.

I'm assuming the following:

• Use story points as the unit for planning. I'm assuming this because that means the software will be looking at the velocity of the team, rather than the "time" capacity of the team's individuals.
• Only put story points on epics.

Am I heading in the right direction? I'd kinda like to have a plan in mind before starting my evaluation of JIRA Portfolio.

[Martin Suntinger]

Michael - you're on the right track here! You can basically go "only as detailed as needed" when planning in Portfolio - I generally agree with Steven that the more granular you get, the better understood the stories will be, and the more reliable the plan will be. Portfolio itself allows you to just put in the team velocity without any team members (or a sum of hours capacity if you go for time-based). You can have estimates either just on the epic level, or have them summed up from child stories underneath. I think it is all a question of what you make out of the resulting schedule - as long as you know some timelines are a high-level draft, or they present a time-box in which the team can then manage scope, it works well. Also, we often see a mix of epic-level estimates in the longer term and story-level estimates for maybe the next 2-3 sprints of its needed to get a more reliable forecast, that the team is fully commited to in the very short term. 

[Michael Kelly]

Thanks Martin. I'm estimating 3 months out. Detailed planning for that period of time is a waste IMO. Priorities could easily change, and the work that was so carefully (and time consumingly) analyzed and estimated put on the shelf.

Also, I never ask the team to "commit". In 2011, Scrum abandoned the notion of team commitment to the work selected in a sprint, and I think they were right. The best we can ever do is offer probabilities, "We'd give about an 85% probability that we'll deliver the selected work by the end of the sprint." This is why Scrum switched to "forecast" instead (see: https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/95/Commitment-vs-Forecast-A-subtle-but-important-change-to-Scrum). Myself, I prefer "target" because it makes it more game-like.

But I'm venturing into the realm of religious wars. Thanks for your prompt responses. I now have what I need to proceed with my evaluation of JIRA Portfolio.

[Steven F Behnke]

I can hardly add on to that answer.  Thanks Martin!