My team at Thrillist begun to experiment with Portfolio for JIRA to build our 2016 roadmap with the goal of getting off of spreadsheets and staying synchronized with the reality of our progress. The concept of linking our JIRA projects to our roadmap got me excited to start using Portfolio. The tool is powerful and can be a little intimidating to the user who is just starting to play around with it. I was excited to learn that Martin Suntinger, the principal product manager for Atlassian's portfolio management software, was giving a talk about lessons learned and the future of the tools.
For those not familiar with the tool, JIRA Portfolio is a representation of your team's backlog, estimates and priorities on a gantt-chart-esque schedule. The ticket heirachy is familiar to JIRA users: small tasks are called stories and they can be grouped together to accomplish an epic. Portfolio takes this heirachy to another level by allowing you to group epics together into initiatives. Initiatives are meant to be high-level business objectives. The roadmap is updated automatically as work is completed (measured by logging time or resolving tickets).
After all of our work was imported, estimated and prioritized, we were a little puzzled about how Portfolio determined what we should work on first. Martin was able to clear this up for me. The algorithm uses the following logic for starting work: Firstly, what is the rank of the epic? The epics that live at the top of the backlog will be completed first. However, this logic can be overruled if there is an epic assigned to a release with a deadline. For example, if Epic 1 is ranked ahead of Epic 2, Epic 1 will be started first. However, if Epic 2 is part of a release, Epic 2 will take precedence to ensure the release date is hit. There are other configurable constraints that factor into the decisions such as what skills are necessary to complete the task and how many people can work on a particular task simultaneously.
"A great plan should trigger tough discussions and decisions" - Martin Suntinger
Our initial reaction to the plan that Portfolio suggested was "wow, these things are going to take longer than I thought." It was nice to hear that this is a common response from most teams. Martin warned "realistic forecasts can cause temporary shocks and disillusions." In spite of the shocking forecast, it is difficult to dispute the data. This tool enables us to have meaningful (and sometimes difficult) discussions about what should be prioritized. It is no longer an option to "shove" something into a release and "just get it done." With Portfolio, the team must shuffle priorities and sacrifice features to hit dates that are at risk.
The future of Portfolio looks promising. Martin showed off the next version of Portfolio due out early Q1 2016 (according to their own Portfolio plan!) and it includes some useful features such as importing data from agile boards. The next version will also enable us to create our own heirachies (we will not be bound to the story, epic, initiative heirachy) and subtasks will be supported as well. There is also a plan to incorporate "snapshots" so that what-if scenarios can be compared side-by-side and provide the ability to "look back" at how a plan looked at one period of time so that it can be compared to today's plan.
I spent a good amount of time at the Portfolio booth asking questions, learning about the new product and chatting with both the team and fellow Portfolio users. It was encouraging to hear from Eric, the VP of Software Engineering at Rosetta Stone, and learn about the successes his team has seen using Portfolio. We will continue to monitor the progress of our roadmap at Thrillist using Portfolio and anxiously await the new features. Congratulations to Martin and his team for creating a creating a great product and best of luck on the evolution of Portfolio!
Maurizio Mancini gave a talk where he dished out some inspiring knowledge: "QA is not the quality police -- everyone owns quality." Developers should build with quality in mind rather than "throwing code over the wall" to QA teams. This sounds like an obvious mantra but often QA teams will bloat their test cycles by trying to test everything. Instead, if quality is built in from the start, QA should only test components where issues would result in high impact to the product and high visibility to the user. Components that will result in medium impact with medium visibility should only be tested if time permits, and low impact/low visibility components do not get tested.
The topic of scaling product and development teams was covered by a variety of speakers from Rosetta Stone, to Amgen, to Atlassian. All of them had slightly different approaches but they all shared some common themes. Most referenced the textbook SAFe (Scaled Agile Framework) flow and adapted it to their own needs. Everyone mentioned the importance of aligning Sprints across all teams. This means that everyone is working on "Sprint 1" at the same time and everyone will begin "Sprint 2" at the same time. This way, all teams know what and when everything will be delivered. Each team also discussed how they leveraged Portfolio for Roadmap management!