Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,298,788
Community Members
 
Community Events
165
Community Groups

JIRA (& other tools) not supporting Agile principles

Many experts and experienced people in the Agile world are sceptical of tools like JIRA which are used in so many companies these days. I support most of their points too. Some of them for a discussion here (If there is a user voice list where we can request for features, please let me know). I'm posting here for now :

  1. JIRA does not support the Whole-team approach
    • Issues can only be assigned to one person in the team -> This makes the teams create new columns in the Sprint board and this creates the "Throwing over the wall mindset". It will be great if one Issue can be assigned to multiple persons -> Dev, QA & PO for example.
    • Why is there no "Test/Test case" type by default ? -> This makes the teams look for separate test management tools isolating the QAs and Devs again. It doesn't have to be very sophisticated, just a table format for the steps could be sufficient.

  2. No Story mapping tools out of the box -> Backlogs are 2-dimentional. Planning is difficult and difficult to create a Value based feedback from the end users/customers which is the most critical component of Agile. So, why not a blank Whiteboard where things can be moved around like a real Whiteboard and not a standard 2 dimensional backlog
  3. Different types of Estimation -> For example, something like a T-shirt approach with S, M, L or XL is not possible. It's normally based on story points or hours. 
  4. Not possible to visualize a tree structure of the Issues -> Epic-> User stories -> Tasks -> Test cases etc. It's only possible to see a 2D view. 

What do you all think ?

3 comments

Some of this is historical - Jira started to support Scrum and Kanban a while after it was written as an issue tracker.  Some functionality is not quite what you think it should be because it is layered over something it is not designed for.

So, with that in mind

1.  Multiple assignees are an unmitigated disaster in almost every development process, Scrum and Kanban included.

But, Agile doesn't actually say anything about assignee, it does suggest that you work as a team.  And the team uses a board to track their items. 

So Jira absolutely does support the whole-team approach - the board is the team.  If the issue is in their backlog or on their board, it' is "assigned" to that team.  A lot of teams then use assignee to say "Charlie is taking this one, no-one else pick it up".

In your scenario with the three different roles, that's also fine, and actually more accurate and useful - the assignee changes as the issue progresses, representing who is currently responsible for getting it done within the team.

There's no test cases by default because 

  • Jira was not written as a test management tool
  • Scrum and Kanban expect testing to be done as part of the story, testing is not a separate activity

2,  Whiteboards

Would be a nice-to-have for some teams, for sprint-planning, especially if you could then turn it into your backlog when you've got a good plan.  But remember that you've already got an overall goal and a product owner with a good view of that, to help the team get their backlog prioritised.

3. Scrum estimates have to be numeric. 

You can't calculate numbers from strings.  That said, when I first ran into Scrum in Jira, I wrote a plugin to do it - a simple select list that held a standard list of options as per the built-in select list, but it also held a numeric mapping.  So you'd enter XS (1), S (2), M (3), L (5), XL (8), XXL(13), XXXL (21).  It output that in a numeric field, so you could use that as the Scrum estimate.

(You'll note I did not mention Kanban there - Kanban does not have estimates)

4. Agile doesn't prescribe hierarchy

Jira's core function is an issue tracker, so when you start doing Scrum or Kanban with it, that's the natural layer you create sprint items at, and Kanban cards.  Of course, we all find being able to break stories up into pieces useful, hence sub-tasks, and then grouping stories together with Epics/Features and more layers above them also.  Jira does the basics, and gives you some simple structure stuff, but Atlassian have leaned on partners rather than do it themselves, so there are some excellent apps around that add layers - Structure, Big Picture and Easy Agile for example.  They've also acquired a couple for doing it - Advanced Roadmaps is based on a partner's "Portfolio" and Jira Align (Agilecraft)

So, you've got some interesting questions there, but none of them really lead to "Jira isn't Agile" - it's more the opposite, it's actually better at Agile than a lot of other tools that pay lip-service to it.

Like # people like this

Well, TBH, It seems to be more excuses to me - considering the time that JIRA has existed now and the size of the market and the number of users (my current project has more than 15000 users in JIRA - you may calculate the money involved).

The chief complaint remains - that Atlassian has not tried to move more towards supporting the Agile principles while claiming lip service in their documentation and marketing materials.

The worse thing is that they don't seem to have any goal to move in that direction. The marketplace licensing thing is a total disaster. We have to buy 15000 licenses for an app which will be used by 25 people. It doesn't help us either on that front. JIRA may be better than some other tools in the market but being a market leader by a long distance, I expect them to Improve and show some leadership instead of blaming the past. 

Not excuses, just an explanation of how Jira has ended up this way.  They're not blaming the past either, they're just not explaining it much when they do new stuff, because they're focussed on improvement, looking forwards, not back.

>The chief complaint remains - that Atlassian has not tried to move more towards supporting the Agile principles

Um, no, if you re-read the answer I gave, you can see that it's the opposite - they've actively persued all the principles (to varying extents), but while trying to avoid building software that blocks people who are not (or don't really understand) Agile from using it.  More importantly, they've built Jira to support Scrum and Kanban properly, not bodge it like others.

I know people grumble about the marketplace "we only want 25 people to use this", but that exposes a problem in its own right - if only 25 people need the function, then why are they not being Agile?  Agile means having a common understanding of what you're doing, so surely ?if those 25 people need it, the rest of your users do?

Nic, Love the thorough answers and agree with your position. It is better than the others I have seen. I am not a project manager or scrum master with a ton of experience so I may also be wrong but I agree with you all the same!

I've got another question for you. I am new to the Atlassian tools and the community but a small software company owner of 22 years. I don't write code or operate in the development process as far as owning a job or function so pardon my ignorance. I am looking for a project manager, app developer, and AWS admin and was wondering if you have a place to post part-time gigs or know of a great place to look for this type of consultant?

It's not designed as a job posting or recruitment site, but the community does have an area for this sort of thing - post something in https://community.atlassian.com/t5/Jobs-Careers/gh-p/JobsCareers

Like Craig Nodwell likes this
  1. JIRA does not support the Whole-team approach
    • Issues can only be assigned to one person in the team  

Your Jira admin can add "Group Picker" custom fields to your issues. Groups represent many users.
Another way to solve it is for your Jira admin to add a "User Picker (multiple users)" field to your issues.

  • Why is there no "Test/Test case" type by default ? -> This makes the teams look for separate test management tools isolating the QAs and Devs again. It doesn't have to be very sophisticated, just a table format for the steps could be sufficient.

Why - not sure. That's how Atlassian's decided. There are many good QA apps on the Atlassian Marketplace. Alternatively, your admin can add a "Test Case" issue type and you can create tables in your "Description" field. This will be cumbersome, but won't require an app. In the long run, you'll benefit from a QA app.

  1. No Story mapping tools out of the box -> Backlogs are 2-dimentional. Planning is difficult and difficult to create a Value based feedback from the end users/customers which is the most critical component of Agile. So, why not a blank Whiteboard where things can be moved around like a real Whiteboard and not a standard 2 dimensional backlog

Try Jira integrations with existing tools that do this. Jira provides a framework for your worklfows, but user needs are so diverse that it's unable to do everything. That's why Atlassian Marketplace exists and that's why Jira integrates with tools also from outside of the marketplace.

  1. Different types of Estimation -> For example, something like a T-shirt approach with S, M, L or XL is not possible. It's normally based on story points or hours. 

Your Jira admin can add "Single Select" custom field called, say, "T-shirt estimate" having values like "S, M, L, XL". Jira's functionality won't take this field into account, though, so no automatic sprint planning based on it will be there to measure capacity.

  1. Not possible to visualize a tree structure of the Issues -> Epic-> User stories -> Tasks -> Test cases etc. It's only possible to see a 2D view. 

True, but there are many apps on the Atlassian Marektplace that can do this.

Regards,
Radek Cichocki

Marketplace is not an option for us because we have 15000 users in our JIRA instance due to customers also being a part of that. Atlassian makes everything dependent on the number of users in the Instance which does not make sense in anyway. Most other tools can differentiate between the Individual projects for calculating the number of users instead of the whole Instance of JIRA. 

Hi @Abinash Deepak 

There is a possibility that you may need license optimization that would lower your license costs, so that marketplace becomes an option. If your customers are a large part of these 15000 users then you may benefit from converting some of your customer-facing projects to Jira Service Management-type projects where customers are served for free (yes, they do not require a license and still can do much). They interact through a simplified UI called the customer portal.

You can either reach out to an Atlassian Solution Partner near your to learn more about it or contact us (Deviniti) and we will try to help. There may be options that you just aren't aware of yet.

Regards,
Radek Cichocki

Comment

Log in or Sign up to comment
TAGS

Community Events

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

Events near you