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:
Can this be done?
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.
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:
Am I heading in the right direction? I'd kinda like to have a plan in mind before starting my evaluation of JIRA Portfolio.
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.
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.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events