Product Development Q&A and Best Practices
In the PMHQ Slack community, we regularly get thought-provoking questions that we feel should be explored in-depth and documented for future reference. We’re starting a new set of Q&A posts to dive into these kinds of questions, and enable everyone in the community to revisit the answers and contribute further!
“How can I be well-organized on JIRA for multiple platform products? We have mobile, back-end, API, admin panel, etc., so when we start the sprint all our focus is based on user experience, but we need to improve all our products. How should we handle this?”
– Anonymous
First, it depends on how your product teams are structured. Do you have a single team that is tackling all of these initiatives simultaneously, or do you have dedicated teams? Let’s walk through how to organize JIRA for either team structure.
Single Team Approach
If you have only a single team, you’ll need to determine what the goal of the sprint should be for your entire team. Since you’ve mentioned that you like to focus on user experience, set your sprint goals in terms of the user experience that you hope to achieve.
Be sure to set these goals before the sprint begins. Setting goals after the sprint starts is dangerous for a couple of reasons.
First, if you set sprint goals mid-sprint, you’re more likely to set goals multiple times within a sprint. Doing so creates confusion for your product team on what the priority should be, and can demoralize the team.
Second, setting goals upfront ensures that the entire team is aligned and motivated on what they’ll be working on next. By creating transparency towards future work, you create a sense of trust, safety, and clarity for your team.
Now that you’ve set your sprint goals, work backwards. Determine what work needs to be done across all of your platforms to get you there. For example, if the sprint goal is to strengthen the user experience on a particular feature, you might decide that you need to revamp the mobile experience for this feature, add more data to the back-end, and create new endpoints in your API.
Check with your team to see whether this set of cross-platform work is feasible within the sprint. The first few times you do this, you will find that your user experience goals will be too ambitious and that you will need to cut back your sprint targets to deliver within the sprint. This is okay since it just means you’re inspired! With experience, you’ll eventually find the right balance.
Now you know what the team should be working on, create tickets within a single project within JIRA. Generally, I like to map one team to one project, so that looking for tickets in JIRA is more intuitive and less cluttered.
For these tickets, label each ticket with its platform. By using labels, you can create filters that enable your team to quickly get a sense of what distribution of work you have, or you can parcel out particular kinds of tickets to people with particular skill sets.
Note that you’ll want to write tickets that are bound to a single platform, to prevent confusion across your development team. Don’t try to write tickets that span the entire technical stack, or else the work will get lost!
In summary, when working with a single team, remember that the goal is to deliver a particular solution by the end of the sprint, regardless of what platforms you’ll need to touch. Set your sprint goal in advance, create tickets for each relevant platform, and ensure your team can knock them out by the end of the sprint.
If you’re having a hard time finding a great team, you can join the PMHQ community to find like-minded product experts.
Dedicated Team Approach
At a high level, you’ll use the same mental framework as described above in the single team approach, but you should organize JIRA differently when working with multiple teams.
Assuming that you have one dedicated team per platform, you should set sprint goals for each team before the sprint starts.
Then, create one JIRA project for each platform. This way, teams can independently own their own JIRA project setups. In my past experience, I’ve found that front-end teams work differently from back-end teams, and forcing everyone to use the same structure or project creates unnecessary friction.
Your goal is still to deliver a solution across platforms, but with multiple dedicated teams, you can run initiatives in parallel. You no longer need to tie each team directly to the same goal.
Here’s a concrete example: when I had multiple dedicated teams, there was one sprint where I asked the back-end team to invest heavily in refactoring in order to improve the performance time of our applications. Since that work was mostly independent, I had the flexibility of asking the mobile development team to make some UX enhancements, and of asking my API team to modify some of our existing endpoints.
“Are there any best practices for task and issue dependencies which are related to each other? For example, say I am going to add a feature for mobile, but it needs development on the back-end first. How should I manage this?”
– Anonymous
For issue dependencies, it’s best to first create a technical document outside of JIRA that describes the overall end-to-end solution.
That is, if you need a feature for mobile, your document should lay out the goals for that feature, and then lay out what technical work is required across layers to achieve it. From there, you can then create your tickets by using your document as a guide.
As a bonus, having a technical document ensures that your teammates are aligned with the proposed solution, and can raise any questions they might have upfront.
I personally like to use Confluence (another Atlassian product) to create the necessary documentation, then link my JIRA tickets back to the original Confluence page. Since both are Atlassian products, they integrate with one another to surface relevant information.
Note that you can also use issue links in JIRA to see whether there are tickets that are dependent on one another. For the case that you described, where mobile depends on back-end, I would create it this way: Back-end ticket “blocks” front-end ticket. Then, whenever I read my front-end ticket, I will see the issue link and the status of the blocking ticket, to know whether there is a bottleneck or not.
When you use a “blocks” relationship in JIRA, your back-end ticket will report that it is blocking your front-end ticket, and your front-end ticket will report that it is being blocked by your back-end ticket. This yields much more information than a “is related to” relationship in JIRA, since you lose some of the nuances in how the tickets relate to each other.
“We are a small startup, but we’re growing so fast. What we should use in JIRA, kanban or scrum? We have back-end, app (iOS, Android, and admin panel), API, and microservices. It is really hard to manage.”
– Anonymous
I’m excited to hear that your startup is growing so quickly and that you’re actively thinking about how to scale your team! Note that kanban and scrum aren’t just ways to organize your JIRA board – they’re different flavors of development processes entirely.
A quick primer on the two: kanban is where you break out your work into bins, such as “to do”, “in progress”, “in review”, and “done”. In my mind, the key part of kanban is that you can only have a select maximum of tickets in any bin. Therefore, kanban quickly visualizes any bottlenecks in the product development process. If you’re curious to learn more, you can read more about Atlassian’s take on kanban.
Scrum is where you aim to complete a set amount of work within a set period of time, with regular milestones and rituals. In contrast, kanban is a continuous process where work is pulled from bin to bin, with no timeboxing. If you’re curious to learn more, you can read more about Atlassian’s take on scrum.
When it comes to sprint processes, I’ve found that there’s no “right” answer for kanban vs. scrum. My advice is that you test both processes across all of your teams, and then gather feedback on what works the best for each team.
For example, you can run for 2 weeks using kanban, and one 2-week sprint using scrum. For an even more rigorous set of learnings, you can then conduct one more cycle of altering between kanban and scrum, since it’s likely that your teams will discover more nuance behind each development process.
Note that “gathering feedback” doesn’t mean “deciding by committee” – you don’t need a unanimous vote, and sometimes even the process that is most highly voted is not the right choice.
For example, if all of your engineering leads say they like scrum, but all of your junior engineers say they like kanban, you can’t just make a decision based on seniority or based on votes. Ask your team why they prefer one method or another, and incorporate those insights into your decision.
At the end of the day, you are the decision-maker. It’s your call whether you want to implement the same development process across the board, or if you’re comfortable with each team selecting their own way of working.
“We have too many upcoming features, but we need to make our current product more stable. How to balance between these two? Which data will guide us to prioritize our roadmap?”
– Anonymous
Prioritize by estimated impact. That is, what is the impact of releasing any particular feature (e.g. # of new users, % increase in conversion), and what is the impact of not strengthening the stability of your product (e.g. # of bugs, crash rate, # of complaints)? Use the impact to then assess which one is more important.
Note that impact estimations are just estimates, so you’ll have to make the final call based on your own understanding.
Note also that there are times where features cannot be completed without first increasing stability or without reworking the base architecture – therefore, you need to account for dependencies when making decisions.
Also, once you have created a roadmap and some assessment of estimated impact, be sure to review your past roadmap after a couple of months, and check to see whether your estimates were correct.
Sometimes you’ll find that you overestimate or underestimate in particular categories, and so you should adjust how you estimate. After a few iterations, you’ll become quite good at impact estimates, and therefore feature prioritization!
“I would like make a release checklist because I want to make sure new releases are not buggy. What I should do? Which release processes are efficient for startups?”
– Anonymous
I’ve personally learned that you need to create a release checklist by platform and/or layer.
That is, you need one for back-end, one for mobile apps, one for web/desktop, one for API, and one for microservices. This is because each platform/layer has different sets of critical tasks. A “global checklist” rarely works well.
Generally speaking, you’ll want to check for the following for each layer:
- Technical: unit tests, integration tests, performance tests, backward compatibility tests, regression tests.
- Design: user acceptance tests, visual consistency across apps.
- Marketing: marketing assets, internal communications, external communications, App Store / Play Store screenshots, and descriptions.
For example, my mobile app checklist looked something like this:
- Conduct user acceptance tests and ensure that the app meets stated goals for the customer and for stakeholders.
- Ensure that unit tests, integration tests, performance tests, backward compatibility tests, and regression tests have all passed.
- Conduct a visual sweep to ensure app is consistent with brand guidelines.
- Write up internal communications and release notes.
- Work with marketing team to determine external communications and align on App Store / Play Store screenshots and descriptions.
- Compile final production-ready app and circulate internally for final sanity checks.
- Release app to App Store and Play Store, monitor release for download statistics and bug reports.
That checklist looks completely different from an API checklist, for example, because APIs don’t have visual elements to check for. Instead, for my API release checklist, I ensured that dependent engineering teams and external API users were aware of the upcoming API changes.
Be sure to circulate your release checklist with each development team and with internal stakeholders. By doing so, you set clear expectations for the team, and you’ll know exactly when you need to pause the release. If any step in your checklist fails or is skipped, you need to dive in and learn why such an event happened. From there, you can determine whether that step is truly critical for ensuring the success of your release.
Best of luck!
Have thoughts that you’d like to contribute around best practices in using JIRA? Chat with other product managers around the world in our PMHQ Community!
