Thanks for joining us for our April 20th and 21st From theory to practice: optimizing agile team delivery webinar. If you missed the webinar, want to share it with your team, or watch it again - here’s the link.
Joyce Vargas, an agile scrum master at Atlassian showed how to:
Maximize team effectiveness and agility with the scrum framework
Use Jira Software and Confluence Cloud to drive the most value for your team
Evolve your team’s agile capabilities
We had over 900 questions during the webinar, so we’re sharing the most commonly asked questions & answers. We know you’re hungry for more agile resources, and we plan to deliver! In the meantime, here are the resources that we shared in the webinar:
We also offered a webinar last September on “How to use Jira Software and Confluence Cloud together” if you’re looking for more tips on managing agile projects!
Q1: What is your recommended frequency and length for a team’s Scrum events and meetings?
*For shorter Sprints, the event is usually shorter.
Q2: When do you do Refinement and how much work should you have refined at any given time?
Product Backlog Refinement is an ongoing effort to get work ready for a sprint. The Scrum Guide intentionally does not prescribe any cadence or timebox for Refinement. Teams are empowered to choose their own, preferred cadence.
Joyce’s team has a Refinement workflow (visualized on a Refinement kanban board) with many steps, including a designated Refinement meeting. Think of the design process, as an example. There are many steps in a design workflow, but you may choose to have a designated design review meeting for the team to sync on the latest design work. For Joyce’s team, the designated Refinement meeting occurs daily for ~45 minutes, with the entire team (Product Owner, Scrum Master, and Developers). Stakeholders and/or subject matter experts are also invited on an ad hoc basis, as needed. If there are enough stories refined, the team simply cancels the meeting or ends it early.
While not required, Joyce recommends having no more than 1-2 sprints' worth of work refined at any given time. Ultimately teams only need enough work refined for the next sprint. Refining too far out increases the risk that business requirements or customer needs will change. It is not worth the effort, as you would likely need to re-refine the work, as you get closer to the sprint.
Q3: How do you manage large stories on the Refinement board that need to be broken down into several smaller stories?
As stories move across the Refinement board, the fidelity of the team’s understanding moves from uncertainty to definition. For Joyce’s team, this means they start with a single story and then break it out into additional stories as new learnings surface during Refinement. These new Jira issues are treated as net new stories. They start in the Product Backlog and move through the Refinement workflow.
When in doubt, it’s always good to split a story into a small unit of work. This minimizes the effort, risk, complexity, and uncertainty tied to the story - and ultimately, it's dependencies. This is the concept of “Independent” stories, from the INVEST criteria.
Q4: How do you prioritize “non-feature” work?
Some examples of “non-feature” work include maintenance, enhancements, tech debt, and refactoring. While these may not always demonstrate visible customer value, the work is still valuable and necessary.
As this work is often invisible or “under the hood”, sometimes the development team will need to surface the necessity to the Product Owner. It’s then up to the Product Owner, in collaboration with the development team, to prioritize the work as they would for any Product Backlog item. This scenario is an example of the Scrum Pillars (Transparency, Inspect, Adapt) in action.
For Joyce’s team, they choose to dedicate a small part of every sprint to tech debt. This choice came out of a team Retrospective discussion. It ensures that “non-feature” work does not get lost and tech debt does not build up. And it ultimately sets an expectation for the team to regularly uphold quality.
Q5: How does testing fit into a sprint? Often our development happens in one sprint and testing rolls over to the next sprint.
Lean/agile QA could be an entire webinar itself! At a high level, testing in an agile environment requires applying agile principles to the QA workflow. How you refine informs how you build and in turn informs how you test. Going back to the INVEST criteria, the key is to break stories down into Small and Vertical/Valuable increments.
For example, a Vertical story would include both development and testing. This is because it only provides Value (and it’s only shippable) to the customer if both development and testing are completed. Fitting both development and testing into a single story is only possible if the story is very Small.
A common occurrence is for QA to remain idle in the beginning of the sprint, and then receive a pile up of stories ready for testing at the end of a sprint. It is impossible for QA to test a sprint’s worth of work within this short timeframe, and thus testing inevitably rolls over to the next sprint. Small stories (even with both development and testing effort) have a higher chance of being completed within a sprint because they have less effort, risk, complexity, uncertainty, and dependencies tied to them. They are more manageable and less likely to get blocked. Doing the due diligence of breaking down your stories into Small increments during Refinement will enable them to flow across the board to “Done” throughout the sprint.
Q6: What is the determining factor of moving a bug to the Product Backlog versus handling it within the sprint?
For Joyce’s team, a bug stays within the sprint if it falls within the scope of the acceptance criteria of a story within the sprint. If a bug is found during a sprint, but is not relevant to any story’s acceptance criteria, then it moves to the Product Backlog (in order to go through the usual Refinement workflow). This is Joyce’s team’s preferred Sprint Protocol, in order to cultivate focus and commitment within a sprint. However, it is not a requirement. The Scrum Guide states that “During the Sprint:… Scope may be clarified and renegotiated with the Product Owner as more is learned.” This means that it is possible for the Scrum team to collectively determine that a newfound bug is higher in priority, and therefore choose to keep it in the sprint, even if it is out of scope of the original sprint plan.
Q7: What are the best practices for agile estimation?
This could be another standalone webinar! At a high level, here are a few of Joyce’s recommendations on agile estimation:
Estimate using relative values (e.g. effort, risk, complexity, uncertainty) instead of absolute values (e.g. time). For example, if I have two glasses that contain different amounts of water it would be easier and more accurate to estimate the volume of water with relative values (i.e. there is a small amount of water in this glass, and a large amount of water in that glass), rather than absolute values (i.e. there is 8oz of water in this glass, and 13oz of water in that glass).
Estimate collectively. Instead of a developer estimating for development effort, a tester estimating for QA effort, etc… have everyone on the team estimate for everyone’s effort. This will be a more accurate reflection of reality because it accounts for all of the actual work that needs to get done. It also encourage cross-functional empathy, reminding team members to consider other people’s workload. As team members get better at considering everyone’s effort, they get better and more accurate at estimating.
Anyone that is not a development team member (e.g. this could include managers, stakeholders, the Scrum Master, or the Product Owner) should not estimate the work. On Joyce’s team, there are developers, QA, and design team members. They all participate in estimation, regardless of whether the work involves their discipline. This again, promotes cross-functional empathy and helps everyone get better at estimation
Aim for conversation, not consensus. There is no right answer when it comes to estimation. Every unique team has their own benchmarks and mix of experience. This means the same piece of work could be estimated as “5 story points” for one team and “21 story points” for another - and both could be accurate. Teams gain more value through conversation than consensus, because it helps them align on a shared understanding of what “5 story points” means to them, uniquely. It also helps them learn/discover effort required that they were previously unaware of. The next time they estimate, they will be able to incorporate this learning, and improve their estimation.
Q8: Does swarming conflict with the Mythical Man Month?
The Mythical Man-Month: Essays on Software Engineering is a book written by Fred Brooks. Its core message is that "adding manpower to a late software project makes it later” (also known as Brooks' law). Adding additional/new team members slows down delivery because in reality, it takes time for people to ramp up and learn how to work best together. This does not conflict with the concept of swarming because swarming assumes that your number of team members are fixed. Any given number of team members may swarm on any work, anytime during a sprint. The longer your team members have worked together on the same team, the better they will be at working with one another. This, combined with swarming (which enables shared knowledge and removes the need for ramp up or handoff time) is a recipe for increased efficiency.
Q9: How do you tackle the problem where individuals are allocated to multiple teams? Or if Scrum roles are combined (e.g. a Scrum Master who is also the Product Owner).
The Scrum framework prescribes 3 roles (Scrum Master, Product Owner, Developers) that are distinct and dedicated. Combining Scrum roles or allocating individuals across multiple teams means you are not doing Scrum. Unfortunately there is no easy fix to overcome this challenge–because the framework is not being used as intended/designed. Addressing the root issue (i.e. setting up your team with distinct and dedicated roles) is the best solution to set your teams up for success.
Q10: How do you measure team health?
Teams have the freedom to use their preferred method to measure team health. One method that Joyce uses is to send the team an anonymous survey every sprint (e.g. a Google Form). The survey asks team members to rate their happiness for the sprint on a scale of 1-5, with 5 being very happy. From there you can calculate the average from your results and plot it on a chart to see trends over time–as Joyce showed in the webinar.
Another method that Joyce uses is to incorporate team health as a prompt during the Sprint Retrospective. For example, your Retrospective prompts could be: “Went well”, “Could improve”, and “Temperature check” (scale of 1-5, with 5 being very happy). It’s important to have each team member write their “Temperature check” individually first, before sharing with the group - in order to foster honest answers and avoid cognitive bias.
Lastly, we also have a Team Health monitor in our Atlassian playbook.
Q1: What are the best ways to learn how to use Jira Software for my team?
Learn agile with Jira Software: Check out our step-by-step guides to greater agility with Jira Software
New admins, we have some best practices just for you too.
It’s also a great home base that links off to related articles, videos, and product documentation. If you are looking for more formal training Atlassian University has on-demand training and certification programs
Q2: How can I create templates in Jira to pre-populate information such as your definitions of ready or done and user story templates
Using Jira automation, you can create rules that populate specific information within a Jira issue based on the issue type. For example, you have user story templates, bug templates, or spike templates.
Jira can populate specific information within the issue description when you open that specific issue type. You can start really simple and add depth as it makes sense for your team. Learn more about automation in Jira.
Q3: How can I create a checklist for reoccurring team tasks in Jira Software?
There are a few ways to this do this:
Using Jira automation, you can set up a rule that whenever you create a certain issue type that sub-tasks with automatically be created. You can start really simple and add depth as you go. Check out our tutorial to learn how to automatically assign created issues based on criteria. Visit the Jira automation template library to see more way that automation can save you time.
The Atlassian Marketplace is home to thousands of integration and ad-ons to Jira Software, a lot of which are free! Head over to the marketing place and explore check-list add-ons.
Q4: How do you have one board feed into another in Jira? (referencing the refinement board into the sprint board).
Joyce and her team started with a Jira Software team-managed scrum project template which includes a few key screens–backlog, roadmap, and sprint board. Since Joyce and the team find value in visualizing the process in which their stories are defined as well, she worked with her Jira admin and set up a workflow scheme that matches all of the steps that work goes through from the backlog to done.
In the board settings of the kanban and scrum board, each step of the workflow was mapped to the appropriate board so the team has a holistic view of where the story and work is. Learn more about Jira Software workflow best practices.
Q5: What can use in Jira software for capacity planning?
Jira Software has robust reporting capabilities from agile reports specific to scrum, kanban, to work management reports within your Jira project to dashboards that are completely customizable. Learn more about status & reporting best practices.
If you are looking for capacity planning across teams Advanced Roadmaps allows you to plan and track work across multiple teams and projects. Designed to empower teams at scale, you can plan based on capacity, track dependencies, manage competing priorities, and explore alternative scenarios.
Q1: What tool do you use for a calendar visualization to understand team capacity?
Team Calendars is a feature in Confluence Premium–it helps teams track who does what when. You can get more information here.
Q2: When is automation in Confluence coming?
This year! Learn more on our Confluence Premium roadmap: https://www.atlassian.com/software/confluence/premium/roadmap
Q3: How can we weave Confluence into an agile project?
Use Confluence to document product strategy, requirements, and decisions.
Link Confluence documentation directly from Jira.
Try templates in Confluence like the project plan template to define scope and map milestones, the sprint planning template to organize sprint planning notes and plan goals and capacity, and the sprint retro template to keep everyone accountable.
Explore Team Calendars–a feature in Confluence Premium that can help with capacity planning and provides a single visualization for team schedules.
Q4. How do you integrate other business areas into Confluence, e.g. Marketing, Support, C-Suite?
Standardizing templates is one way. Our strategic planning template collection includes templates for creating a vision, doing a SWOT analysis, and setting OKRs. When the whole team is setting its goals, use Confluence!
Get an executive sponsor who can help spread the word and encourage (or mandate) using Confluence to share information and capture knowledge. Have leaders share their updates here!
Replace status meetings with Confluence pages.
Share news with blogs (have every new hire write an intro blog and share info about themselves).
For marketers, in particular, we have an e-book and more info here.
Jessica TaylorAtlassian Team
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events