In January, two of our very own Atlassian Confluence product managers, Sherif Mansour and John Masson, hosted a live webinar where they shared agile best practices that they’ve learned over the years, including:
- When to write product requirements documents and when to seek alternatives
- How to write effective product requirements documents
- How to build prototypes when designing new features
- Using Jira and Confluence for product management
Watch the recording, share it with your team
If you’re interested in product management and agile, this webinar is must see. Enjoy!
Q&A with our Confluence product managers
There was so much information we couldn’t get to in just one hour so we decided to do a Q&A session with Sherif and John. Take a look at the top 10 questions we heard from attendees during the webinar.
1. How do you know you’re doing agile right?
Even though we like to tease and use the phrase “doing agile right”, there is no “right” way to do agile. If you want to measure the effectiveness of what you’re doing, then ask yourself:
- Are you shipping the right thing to customers?
- Are you shipping on time?
- Are you shipping frequently?
- Are you learning from each release?
If you answer “yes” to the questions above, it doesn’t matter what exactly you’re doing because it’s “right” for your team. Sure, there are agile practices to help enable us achieve these things, but following these practices religiously and regardless of the outcomes misses the point.
2. How do you model your team’s structure inside Jira and Jira Agile?
There are two broad approaches that we see a lot of customers using, and we mix and match these internally, too, depending what we’re doing:
1 project used by many teams:
This works well where there’s benefit in having all teams using the same workflow, and makes it easy to reassign tickets between teams. It’s works well when you have small teams working on a common goal, such as the Confluence sub-teams described in the webinar.
1 project per team:
Each team has their own Jira project and their own Jira Agile board for that project. This gives the team complete control without having to worry about impacting others. The trade-off for this approach is that you’ll have more overhead and less visibility between the teams, especially where different workflows are used.
But if teams are working on independent work, for instance, different products, this is a sound approach.
How do you deal with the seemingly infinitely growing backlog of features?
This one is a bit like going to the gym. There’s no quick fix, and you need a solid routine that you follow week in and week out to stay on top of it. It’s hard and diligence is the key.
Having a defined triage process that is ongoing and has an owner is essential. At the end of each release you should also have a “clean-up” of things you didn’t get to. Be aggressive, either close it, or move it to a separate “someday” list if you really want to tackle it later. We make these issues public so we can gauge demand and see whether or not they are really valuable.
On the Confluence team, who decides on priorities for new features?
Product Managers decide on the high level roadmaps, user stories, and work collaboratively with the team to help define requirements. To do this we’ve got plenty of input – customer interviews, your feedback on jira.atlassian.com, customer site visits, strategic direction, big bets (gut-feels), feedback from our support team, and reactions to shifts in the market landscape and direction.
Who prioritizes new features, etc.? At Atlassian, we’ve introduced a “feature lead” role. A feature lead is still primarily an engineer on the product, but they pair closely with product management to help define and prioritize features. When product management and engineering are aligned, the feature lead takes on the responsibility of making the day-to-day decisions of backlog priority.
The key thing here is a very close relationship with your engineering counterpart. You have to be like a married couple. You need to hang out all the time, share (customer) experiences together, sit next to each other…but I’d make sure you draw a line in that analogy somewhere! When you’re on the same page, you cover each other’s blind spots, you trust each other, and together, you help your team build amazing software.
How do you handle QA and test cases when you have minimal requirements documentation?
For context on this one, in our original webinar, Sherif said something quite controversial – we avoid writing requirements documentation for features where possible.
Where we do have less formal documentation for a feature, QA get involved in the user journey / sketching / interviews / prototyping process, or whatever we’re doing in place of documentation.
QA’s job here isn’t to do testing, it’s to identify risks / potential bug patterns in the work and advise the Devs on focus areas for their testing. Getting involved early can help identify and mitigate a lot of these before they become real problems.
At what point during the planning process do you decide when extensive documentation of requirements is necessary?
Great question. This is quite an organic process for us. We always try to start as small as possible. Over time, as we learn more about the problem that we want to solve, we make a call if we need to take a step back in our problem definition. We’ve outlined this process in detail in our agile requirements blog series. See the following:
- Walking the requirements documentation tightrope in an agile world
- Agile requirements documentation – a guide
How to you balance between short term goals with the longer term product life cycle architecture?
There’s an important thing to note up front about the premise of this question. A short term solution that doesn’t scale is ok – you learned that the solution was valuable, and had demand, and now invest in improving it.
Confluence Tasks is a good example of this. We started light weight, just tasks on a page, and we’ve had requests for reports, due dates, etc. – and it turns out that we actually need to re-write Tasks to support all of this.
In the process though, we learned that this additional functionality was really valuable to people, and yes, we’re now spending some time refactoring to add to it, but that’s way less expensive than up-front effort on something that never got used.
This is a balancing act though, and in some cases you really need to start thinking long term. We try to make the right decisions by:
- Involving our product architect as much as possible.
- Having a clear roadmap of features that the technical team can see and call out patterns that mean there’s some underlying infrastructure work that we need to do.
- Not trying to anticipate every problem in the long term, it’s ok to uncover them once you’ve seen success.
How do we justify the time to build a prototype when we have short time to development?
I’d flip this question on it’s head, and work out how you’re going to mitigate risk with a short time frame.
In our Do Agile Right for software engineers webinar, Anatoli, one of our engineering team leads, said “spiking” (prototyping) is something he couldn’t live without, because it enabled him to define the risks involved in a piece of work – and how they can be mitigated.
If you calculate the opportunity cost of building the wrong thing, and compare that to the time to make a prototype, you can weigh what you value more – delivering ‘something’ on time, or building the right thing. It’s a big discussion and you need to involve all stakeholders, but we believe, in a lot of cases, that it’s just too risky not to prototype, especially when timelines are tight.
How are the remote teams included when there is so much in writing or drawn on the walls?
Great question! We’re still learning and trying new things, but we can share with you what has worked well for us so far:
- Video conferencing – We’ve got HD cameras setup and often video chat with teams from across the globe. We would walk through physical walls together (journeys, user story maps etc.)
- Daily video standups – We have stand-ups on video, this works quite well for us in staying connected around our daily scrums.
- Hipchat all day, every day – This is the perfect way to stay connected informally so not all the interactions have to be scheduled via video conferences or stand-ups.
- Everything ends up on Confluence pages – A lot of information is transcribed asynchronously in Confluence pages and comments such as meeting notes, requirements, and decisions. They’re then shared with distributed teams who can respond so everyone can stay on the same page.
One of our customers shared their story at Summit 2013 regarding how they work remotely using Confluence and Hipchat. See: “I work in Pajamas”
Live Q&A with Sherif and John
Now that you’ve read their answers, see them present them live for even more detail.
Want to learn even more about agile?
We’re very passionate about agile at Atlassian. Take a look at our learnings on our Agile microsite. We cover everything from Scrum and Kanban to delivery.