JIRA — Product Managers tool
As a product manager I have experienced problems at two levels
Defining vision : when several features were delivered without actually adding any value to the organisation.
Adoption: when a feature expected to deliver value missed out in doing so because minor details were missed out and was not adopted by the end users.
Building the right product and getting the product right in the agile world is a universal need today. Building and shipping great features in a product mandates the team to have visibility of higher, organization level problems as well as minute details to ensure that features being shipped solve for most use cases and in doing so are addressing the organizations priority. So how do you make frequent changes to your product yet not lose the sight of your vision?
One SaaS tool that has been useful for me and like me to millions of users around the world is JIRA (150,000 customers, 10m MAU, 190 countries). JIRA has evolved from being a bug tracking tool to a complete agile planning suite. Below are 3 key features that have helped JIRA become the darling of the early-stage agile adopters.
This writeup is about one of JIRAs features, widely getting adopted as more and more companies move to agile way of working: breaking down higher level problem statements into small manageable chunks of work, laying out a clear map of priorities and providing its current status.
Elements of the map:
Initiatives(with jira portfolio) : To define vision I can create initiatives that I will be taking up this year. For eg., I had taken up an initiative of providing “best in the industry visibility for our seller partners”. This initiative was then broken down into various “epics”.
Epics: These typically span multiple sprints. For eg., I created a epics of providing “Real time inventory visibility to seller partners” & “Dispute Management section” both falling under the initiative of “best in the industry visbility”.
Stories: These are small, 2–3 day executable workloads that give clear understanding of what journeys are getting affected, for whom and why (persona+need+purpose). For eg., “As a seller partner I should be able to see the inventory of my key skus right on the homepage”.
Tasks: These are further smaller system level changes that need to be carried out to complete a story. For eg., for the above mentioned story, a task can be, “Order Management System must pass the real time inventory count to portal”.
Creating the map:
Epics as milestones: Epics must be viewed as important milestones to our destination ( initiative). Epics can be clustered by linking to a initiative. When defining epics you can customize and define the components that will be changed when delivering this epic, if the epic spans multiple components.
Stories as route: Once the milestones are defined, we must create a route to these milestones and stories are just that. Stories can be tagged to an epic, so that they can be viewed in the larger scheme of things. Stories then must be part of the overall backlog and must be marked for specific sprints so that we know how we are going to reach to the destination ( epics -> initiatives) that we set out for ourservels. JIRA provides linking features such as…
“Relates to” : This linking provides you visibility into if some stories or epics related to each other. Creating this map provides developers an ability to evaluate dependencies (upstream or downstream) and provide a solution that is wholistic and robust.
“Blocks”: This type of linking provides you visibility into what stories or epics will not move forward until this story is complete. Creating this map provides visibility and drives urgency among product, program and engineering teams to ensure progress by resolving the blockers first.
Navigating the map:
Burn down charts : These show you how much you have progressed in the journey as against what the map initially showed you. How many stories have been “burned”? how many are pending ? Are we moving too fast or slow than anticipated?
Agile boards: These tell you where exactly do you stand in your journey. What are the few next immediate milestones you will achieve or have achieved in the past few weeks? If one wants to see how this is affecting the journey, then one must see a slightly zoomed out view.
Velocity charts: The analogy here is that of your cars mileage in the journey. Velocity charts show you how much your teams can deliver in a specific sprints. Observed over few sprints this can give you a picture of what additional resources will be needed or can be re-arranged from other sprints.
JQL (JIRA Query language): At any point in time in journey if you want to see specific details, you can use JQL to search for items with Issue type, Project, Priority, Fix Version, Epic tag etc. For example you can use it to know the progress of your epic by simply searching for issues with epic tag.
“epic name” = “Dispute Management section”
Or specifically high priority items within this epic
“epic name” = “Dispute Management section” AND priority= High”
Dependencies report( available with jira portfolio): Helps visualize dependent/linked stories so we know where and why we are stuck at a point in journey (if we are). Completed items are striken-off so the stakeholders know which items are completed and which are remaining.
The Value-add:
How does this hierarchy help the users?
Macro and Micro vision at the same time: Depending on the hierarchy of the user in the organization, the user can know where are we falling short off in defining or executing our vision. For example as a CEO I would be interested in the tracking the progress of the initiatives, and if I wanted to know if a particular initiative has been broken down adequately I can get to see micro level details and conclude may be this initiative requires lot more detailing or if key resources are working on the most important items. Or if I was a developer I exactly know the task I am working on contributes to which initiative of the organization.
Non-technical language: Initiatives, epics and stories are expressed in the form of end-user stories and this provides key context to the developer of the software and makes adoption of JIRA easier for people who do not want to get confused by the technical jargons. This also gives developers an opportunity to think outside the box and not be constrained by technical boundaries.
Course correction: One of the 4 tenets of the agile manifesto is “ Responding to change over following a plan” and this feature provides that ability. While stories get delivered in sprints, the planners can review if these small steps are contributing to the long journey planned out. Epics can be edited to create new stories or delete some stories to do course correction.
Point in time status: At any point in time users can login to know the where do we stand today. How many epics are yet to be completed? How many stories are completed? What are the blockers for stories? Who is working on what? . This is akin to “You are here” map that you would see in a mall or a park.
Reports & Dashboards: JIRA provides a way to automate the reports and dashboards so the users are reminded of the progress. For example, I can keep all my stakeholders informed of what is getting delivered in a sprint by creating a filter and subscribing the stakeholders to this filter. I can schedule this filter for example to be delivered in email to all my stakeholders every Monday morning 10 AM.
Streamlining JIRA has helped me in defining vision in the form of epics; gives me, my team and all the stakeholders in the organisation visibility of what are the top priorities that the product is going to solve. And a clear outline of work that will help all stakeholders identify any gaps that can be there in product adoption. In a way this has also helped me to fix accountability in the sense that it helps me answer questions such as
· Did I define my vision correctly?
· Did I adequately define the vision?
· Did I cover all use cases in defining my product?
· Did I uncover dependencies earlier?
· Did I course correct in time?
Challenges:
1. Feature as anti-pattern: In some jira adoptions, this feature simply has been reduced to way of capturing “tickets” rather than a “Macro to Micro vision map”. As a result the jira instance becomes bloated and ultimately reaches a level where there are lots of “tickets” and the macro vision is lost.
How can this be mitigated: Field mappings must be done such that any micro level ticket getting created should be mandated to be attached to a bigger vision. Regular review and clean-up must be carried out if any micro level tasks seems deviating from the macro vision.
Key metrics to watch out for: # of stories not attached to epic. # of epics not attached to initiatives.
2. Not a replacement to process: This feature of JIRA can only act as a catalyst in defining and adopting a great process, however this can never be replacement. There are articles on the internet indicating how some organizations have treated this as a replacement and have failed.
How can this be mitigated: Using add-ons such as “confluence” to capture various project artifacts such as a complete product note, architecture diagram
3. Regular course correction: Although this feature provides end users the ability to link one story to another story so that as the stories are delivered, impact of delivered story over yet to be delivered story can be assessed, this linking gets complicated when many teams are working in parallel.
How can this be mitigated: Regular assessment of impact post every sprint go live can help us re-organize the map.
Key metrics to watch out for: # of linked stories. # of stories added/deleted for an epic post every sprint go live.
Success:
Despite some of these challenges, JIRA is adding a lot of value to the agile adopters through this feature and enjoys over 30% market-share in project management softwares.
JIRA enjoys 4.5/5 customer reference rating on various sites and below are some testimonials for customers.
“The days of managing work items with sticky notes and a bunch of fragmented tools are long gone. You can’t deliver a quality product at this scale without having tools like the Atlassian suite” — Nate Van Dusen Trulia
“Not only has Atlassian enabled us to work faster and more efficiently, it’s changed our company culture. We are more open and collaborative and we’re able to get products out to customers faster” — Brandon Cipes, OCEAN