nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

We're running a retro on agile––now it's your turn! #RetroOnAgile

juliadillon

Hey, Atlassian Community! My name is Julia and I'm part of the Jira Product Marketing Team. We're currently running a campaign, #RetroOnAgile, to reflect with our users on past software development experiences in order to define the future of software development.

To take part in our #RetroOnAgile campaign, we'd love if you answered one (or all!) of the following prompts:

What's one thing you like about your agile software development?
What's one thing you wish you could improve?
In an impossibly good future, what would your software development process look like?

Post your responses here and be sure to follow the #RetroOnAgile tag via Twitter.

And if you have a minute, check out this blog!

Comments

Sean Regan_r68gz1

I'll get this started.

Several users have suggested the renaming of sprints. To what?

Relays . (Do you have another suggestion?)

If enough people agree, Jira should consider this. It's not a technical feature, it's about how developers work and how we build sustainable healthy software teams.

Sprinting conveys a singular focus on speed. Relay focuses on team speak and successful handoffs. #systemsthinking @#devops . Not....

Sprinting is exhausting. Relays get the best from all but build in time for reflection and recovery.
Sprinting focuses on the finish line. Relays focus on the finish line and the collaboration critical to getting there.
Sprinting treats developers like machines to be optimized and measured above all. Relays treat developers as part of a team collaborating for efficiency, speed, and outcome.

It's a nuance and one easily ignored, but for those of us who spend m-f sprinting, it makes a difference.

Here's the issue. https://jira.atlassian.com/browse/JSWCLOUD-16544

Barrie Treloar

2) What's one thing you wish you could improve?

How we do things by reflecting on how others do it.

There just isn't enough information from start-to-finish on how to use Jira and Confluence on an Agile project.

I don't want to know how to use Jira or Confluence, I want to know how to best apply these tools to run the Agile project.

I can then pick the the areas that have the most pain and look at how we can change our processes make improvements.

Or if I am completely new, just apply the `Atlassian Way (tm)` and have some chance of not needing to rework the process because Jira/Confluence doesn't allow me to work that way. Ideally the information would include why its done that way so people can make informed decisions.

devpartisan

Barrie,

At the risk of sounding defensive, I would say Atlassian doesn't document such a thing because we don't ascribe to the notion of "best practice". Inside Atlassian, there's isn't just one way of doing things that is best for all teams. Teams use practices and tools that work best for them. Outside Atlassian, the "no best practices" sentiment is also common. The idea is that Agile teams are adaptive to their unique situations. And when it comes to tools, remember the Agile Manifesto, "Individuals and interactions over processes and tools."

That said, I understand your overall sentiment as, "How do I start using Confluence and Jira in such a way that I don't make decisions that I'll regret later." For any of our products, the condensed answer is to start simply. I'll try to provide some examples, but maybe there are others in the community who can also speak from experience.

For Confluence, it's really hard to go wrong. Confluence is mostly free-from content, so it is easy to change later. Collaboration flows most naturally when people use Confluence in it's "default open" mode. Trying to create many Spaces early on, with many different permission schemes impedes sharing and creates unnecessary administrative burden. Once a Space is created for an Agile team, let people document what they value. When you have both products, the Product Requirements Blueprint is a great way to start leveraging integration.

For Jira, it's more tempting to try to model all kinds of process detail in the product. I prefer to start new Jira projects, with out-of-the-box defaults, putting practices before tooling. When there's missing information, I use labels for a while. If the habit catches on with the team, then consider custom fields. Even with a custom field, I generally prefer to avoid limiting choices with drop-downs (because many sets turn out to be slowly changing dimensions), or field restrictions like required. Again, Jira's "default open" model is about broadcasting information, not just collecting it.

Workflow is one of the most important aspects of Jira. The key is to remember there are real human implications. If a team doesn't have an agreed upon "flow" maybe it's better to start with a physical whiteboard for rapid iteration over the board layout. This can be an important step to make sure everyone on the team has a say in how they work together, before an admin codifies it in Jira.

Obviously, there's more to learn. Atlassian's site "The Agile Coach" has many great articles that balance our values, internal practices, and what works best with our products. And there are some more specific tutorials that bridge Agile to Confluence and Jira. For that matter, this community has a rich thread of Agilists sharing their own stories.

Barrie Treloar

I hear you Ian, I'm not after best practices, but how to best apply things, as no best practices says "sharing success stories and methods that work is a good idea. Establishing one set of solutions as the best is not."

My background is OpenUp and Use Cases. I don't have any formal training in Scrum. My knowledge is sufficiently similar that I feel comfortable using Jira/Confluence and Scrum to do what I want.

However Jira/Confluence have constraints built into them that are "Atlassian assumed knowledge" and require you to apply Scrum in a prescriptive manner (examples to follow as to why its prescriptive). Presciptive is not bad, it just needs to be explicit and communicated.

If you found someone who is an expert in Scrum but new to using Jira/Confluence and get them to apply the Scrum process with Jira/Confluence then you would find the areas that need better documenting as The Agile Coach and tutorials don't go into enough about why its done that way.

I'd find it valuable following along as they applied Scrum/Jira/Confluence to a small project to see how (and why) they chose to do it that way, and what alternatives are available or were considered.

Here some examples of areas of why Jira/Confluence is prescriptive:

Please Note: I'm not after an answer in this thread. If we can agree that these areas need improving then the improved documentation is where the answers should be.

Epics don't show up on the product backlog

Mike Cohn says there isn't any real difference between Story, Epic, and Theme they are all still stories.

"[an] epic is just a label we apply to a large story."

...

"That tells you that while I did write them, I didn't get the chance to break most of them down into stories that are probably small enough to implement directly."

Yet Jira does not let you put Epics on the backlog, and there is no documentation to tell you why Atlassian made that decision. Themes don't exist in Jira at all, you need to use the Portfolio addon to get that feature.

How to show the subtasks in the backlog/sprint tree?

Mike Cohn says "stories go on the product backlog and tasks go on a sprint backlog" but nothing about sub-tasks, since these are just tasks with some parenting linkage.

There is no documentation that tells you why sub-tasks don't show up in the backlog and what alternative you should be using.

Managing requirements

The tutorial Product requirements documents shows you how to use Confluence, an even talks about "living stories", yet the screen shots all show static information captured in Confluence. I have yet to find anything to explain how to work in both Confluence and Jira.

The priority field is a great example. That field should be pulled live from Jira and displayed in Confluence, otherwise I am finding the field is never used in Jira.

There are plenty of other areas with Jira/Confluence that could be better explained.

These examples are by no means the end.

I am bumping into these types of things as I bumble along trying to implement my processes with Jira/Confluence.

And when you google these questions there are net flames about following the "Atlassian Way" but that way is not documented.

I want one place to look that is well cross-linked. At the moment it is scattered in places and only explains the basic level and I need more experienced advice.

Dave Meyer

Hi @Barrie Treloar,

I'm a product manager on the Jira Cloud team. I totally agree with you that there's plenty of room in both our products and our documentation to reduce the friction for teams to set up a process that works for them using our software.

At Atlassian, we strongly believe that no two teams are alike – different groups of people in different situations will need different features and processes. In our company, we have dozens and dozens of development teams. Almost every single one is "agile" but there aren't any rules about tools, processes, rituals, features that you have to use in Jira, etc. Every team is empowered to use our products and follow practices that work for them. On top of that, Confluence is key to an internal culture where teams are constantly sharing lessons and patterns that help them work together better. In my opinion, this is the "Atlassian Way" more than anything else: a belief in the power of teams to work together to achieve a goal.

But I will be the first to admit that our products are far from perfect. In general, our goal is to enable teams to put in place a process that works for them. We strive for flexibility, so that team's can use Jira's issue types, workflows, fields, boards, and other objects to model the way they want to work. But there are obviously two big challenges here:

Providing enough structure that it's easy to get started with some kind of agile process. We know that almost every team needs to iterate on their process, but in order to iterate, you need a starting point. We want to provide lots of "starting points" for teams at different levels of sophistication in their agile journeys – this is currently a major focus area for us.
When we do take more prescriptive stances in our products, we need to be more clear or offer more flexibility. There are certainly ways that Jira works today that reflect certain approaches to agile development that don't apply to all teams. Not every one of these decisions is one we would make today - we're working hard to take the customer feedback we've gotten over the years and give teams using our products better starting points and improve the experience of setting up Jira Software.

So suffice to say, you're definitely making valid points and we share your perspective that we can definitely improve our Jira Software enables you to put process into practice. It's an ongoing journey.

Cheers,

Dave

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-software-cloud

agile

retrospective