This article is part of a blog series!
| Part | Title |
|---|---|
| 1 | Yes Virginia, even agile teams roadmap! |
| 2 | Moving from roadmaps to requirements |
| 3 | Deliver well: requirements to deployment |
If you’re still with me after my agile heresy, Yes Virginia, even agile teams roadmap!, then I’d like to move down to the next level of the project planning process: requirements. In our roadmap, features are organized into themes that represent a significant enhancement to one of our products.
Product managers work with designers and developers to understand what would be the best path forward to implement a specific feature. Managing risk in a particular feature is an important skill for successful delivery to market. At Atlassian, we use three major techniques to help understand the market and reduce friction in delivering features.
1. Show your stuff!
If a wall is blank, you’re losing an opportunity to get feedback. Feature teams (product manager, product designer, and product developers) at Atlassian focus on workflows and user journeys through new features. The team does mockups and places those journeys up on the wall to understand the larger workflow and also to get feedback from people who pass by. People are naturally curious. We take advantage of the opportunity to get feedback on new features and development very early on in the process.
2. Have one conversation, not several
On the Jira team, release cycles contain eight to 10 two-week sprints. Once the team understands the complete flow of the new feature, the team then figures out how to phase in development over a series of releases. Each release of a feature from the roadmap is listed out on a Confluence page. Let’s take a look again at our fictitious company, Teams in Space:
Product managers list the essential user stories and requirements for a feature in a release on this Confluence page. They then share the page with the entire team to get more feedback. Confluence enables one conversation between the product manager, the team, and any external stakeholders.
The key value add in this context Confluence brings is social currency. Product managers will get a wealth of feedback, both positive and negative. The team and stakeholders will add social currency in the for of likes to the original document, or to any feedback with which they agree. This single conversation makes it easy for product managers to incorporate feedback and ultimately highlight and address key issues in their initiative.
3. Enable development visibility
Once it’s time to start implementation, product managers can easily import issues from Confluence right into Jira. The new Confluence/JIRA integration imports each user story from Confluence into Jira and automatically links that Jira issue back to Confluence.
[youtube https://www.youtube.com/watch?v=reiLHEIlXDc]
Developer Context
Developers can easily jump from the Jira issue they are working on back to Confluence to see the original requirements.
Since the product owner only has one document to update, it’s easy for the development team to follow any changes.
Stakeholder Confidence
I often hear “when will feature X be done?” or “how is the development of feature X going?” Status updates are painful on the product owner or on the development team. Since Confluence links to each Jira issue, product owners have a self-service status portal for all their stakeholders.
Each of the links populates with the latest status from Jira. If stakeholders want to dig in on a particular issue, it’s easy to jump to the right place in Jira to get detailed status.
The more we enable our teams to be self service, the more time we get back in our workday to be productive. Each interruption costs us about 15 minutes of productivity. Use Confluence and Jira together to give both engineers and stakeholders the right level of information and context to minimize interruptions and boost productivity.