In February, two of our very own Atlassian Confluence product marketing managers, Matt Hodges and John Wetenhall, hosted a live webinar sharing agile best practices for software development that they’ve learned over the years. They talked about:
- Agile basics like sprint management and retrospectives
- Planning, communicating, and executing on quarterly goals
- Making the best use of Jira, Confluence, and Jira Agile
Watch the recording, share it with your team
If you’re interested in the agile methodology or how to run a marketing team, this webinar is a must see. Enjoy!
Q&A with our Confluence product marketing 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 Matt and John. Here are there answers to the top 10 questions we received from attendees during the webinar.
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 product to customers?
- Are you shipping on time?
- Are you shipping frequently?
- Are you learning from each release or project?
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.
In agile, is there any way to account for one-off tasks not associated with an epic?
Absolutely. There are tons of issues that don’t fall neatly into our projects (epics). We make use of Jira components to build out our agile board.
Every issue we create in Jira is flagged with ‘Confluence Marketing’. This brings the issue to our agile board and when it’s assigned to me, it will appear in my backlog on my planning board.
Once on my planning board, it’s easy to categorize the issues into their respective epics. But for issues not associated to an epic, I leave them in my backlog until I want to add them to an upcoming sprint.
How did you set up Jira to fit your marketing team’s needs? Any tips for a small marketing team trying to build one?
There are three foundational pillars to how our marketing team uses Jira. First, it all starts with a standard project in Jira. For us, it’s the ‘Marketing’ project. Second, everything we do and manage as a team happens in Jira Agile on our agile board, ‘Confluence Marketing.’ Third, our workflow. For us we have a simple workflow of backlog, in progress, ready for review, done. It’s simple and works great for the marketing tasks and projects we run.
Agile boards are built around the project and components. For us, since we share our board with the Hipchat marketing team we created three components that bring issues to our agile board (Confluence Marketing, Confluence Questions Marketing, and Hipchat Marketing).
For our team, Epics in Jira Agile are our projects. These range from product launches, to webinars, to event sponsorships. Within an epic, we break all the work into stories (Task) and individual tasks (sub-task) as seen in the diagram below.
The final important part to how we set up our Jira Agile board is our quick filters. These make it easy to find the work you’ve been assigned and plan effectively as an individual. We’ve created a quick filter for each person on our team so they can see all of their tasks.
What happened to issues which come during the sprint that are important to include? Typically we readjust the sprint, is this a good practice?
In general, you should avoid adding to the sprint (changing scope) as much as possible. The way we deal with this is by building time into our sprint for meetings and things that come up last minute. We reserve one fifth of our story points for this type of work.
If you find that you are frequently changing the scope of your sprint considerably or are unable to complete your issues as planned, you should also do a retrospective to determine the cause of all the scope change. Is it poor planning within your team? Requests coming from other teams? Or simply the nature of your team that work changes every day? Once you determine the cause, you can adjust accordingly.
I suggest trying a shorter sprint length (one week rather than two weeks) as that should reduce uncertainty in planning. You can also lower the number of story points you plan to accomplish, allowing more time for last minute requests.
We have a large marketing team, over 10 people; do you recommend breaking this into smaller functional teams for the purpose of sprint planning and tracking effectively?
You can definitely do agile on a team of 10 people, though that is approaching the upper limit of what is most effective. Including marketers with different functions in sprint planning is a good idea – you’ll identify dependencies across the team that can end up as blockers. Tracking work and stand ups can become more difficult with 10 people, but if you are disciplined, you can make it work. And if it isn’t working, you can always split into two groups.
Why estimate with story points and not with hours?
We use story points for two reasons, but it has to do with something called relative sizing. First, by using a slightly modified Fibonacci sequence for story points (0, 1/2, 1, 2, 3, 5, 8, 13, 20), it keeps people from being too exact with their estimates, which slows down sprint planning and getting the time of the estimate is less important than how much work it is relative to other stories. Second, the Fibonacci numbers reflect that as a piece of work gets bigger, there is greater uncertainty around how long it will take.
When should we choose between creating an epic or defining a version? I thought an epic was something much smaller than a version, but your examples show they are quite the same size/importance.
As a marketing team, we don’t make use of Jira versions. That’s something much more useful for a development team who might have many epics that divide up the work of a version. For us, epics are projects. So every project, no matter how big or how small, is represented as an epic in Jira. Then we divide up each epic into stories.
For instance, an upcoming Confluence launch (Confluence 5.5) will be listed as an epic. Then we’ll typically create three stories that divide up the individual tasks, ‘promote launch to customers and evaluators’, ‘promote launch to internal stakeholders’, and ‘promote launch to Atlassian Experts’. Each of these stories have a variety of sub-tasks (individual tasks). So for ‘promote launch to internal stakeholders’, an example sub-task is, ‘publish announcement blog post’.
We’ve found that this is the best way to represent the work that needs to get done in Jira. It keeps us organized and gives us structure to rely on for really big projects.
Do you articulate the value of your work at the epic level or task level? Do you commit to work individually during planning or daily scrum?
We estimate work at the task level as epics are made up of many tasks and usually have an unspecified duration – in practice, they last until the project is complete.
We start by assigning each task (or ‘story’) to an individual, and then he or she details the work involved so we can estimate it. Each individual is responsible for committing to the work they’ll finish that day during the daily stand up, but they also commit to what they will accomplish by the end of the sprint during the sprint planning meeting, which happens before the sprint starts.
As a Scrum Master, can you please share your thoughts on focusing the team on what needs to get done even if it’s not what they want to do?
The Scrum Master does all the work to facilitate the agile process and make sure nothing is slowing the team down. The Product Owner is the one who prioritizes work for the team, so it is his or her job to focus the team on the objectives that will drive the project forward, even if they aren’t the most fun.
So, Atlassian, if you could make a wish for particular teams, beyond traditional software development teams, to adopt agile, who would you choose?
Every team should adopt agile in some way. At our core, if you forget about our sprint planning meetings and daily stand-ups, agile is about iteration. We always experiment with our team’s workflow and seek constant optimization.
I think that any team who runs a project should look at it through an agile lens. What’s the best way to make sure that all of the work stakeholders need to get done does? It might just be setting up 2 week sprints to estimate and declare work, running a daily standup, and holding a retrospective to ensure that the next sprint is even better. It might be a slight variation of that.
In the end, though, agile for non-software teams should be about optimization. Teams should intentionally strive to improve their process.
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.