månadsarkiv: maj 2015

Tools to support agile ways of working in large organizations

We are using JIRA to manage user stories and features in an agile setup. I was asked to make some tweaks to the JIRA setup to make the work more efficient.

As with many large organizations, the JIRA setup is managed by a central organization.  Their approach to their work is somewhat less than agile 🙂



Me JIRA admin
May I have a JIRA project to play around in and test some configurations?  I do not want a standard configuration as my changes will affect other projects in that case  
  What standard configuration do you want?
None, I want to be able to change configurations myself.  
  Do you want to be in test or production?
What’s the difference for me?  
  I think you should be in test
  Here’s a project
But it has a standard configuration  
  Oops, here’s another project
Well, this project did not have a standard configuration, but a default-configuration.  But I still can’t change anything.  
  What, you want to change things?
Yes, that was sort of the whole point of this….  
  But then you need full JIRA admin access
Why full access, I only need to change in my project…  
   Then you need full JIRA admin access
Can I have JIRA access?  
  You already have JIRA access if you can log in
I mean JIRA admin access…  
  No you can’t
Can I have my own standard configuration to play with  
  No you can’t
Who manages the standard configuration that is in use here?  
  JIRA admin
Is that your team?  
Who should I talk to  
  JIRA admin

I think I give up……

Difference between priorities and working order

I was recently in a prioritization meeting where the discussion got quite confused and it made me realize one thing…  There is a big difference between priorities and working order (I e in what order you tackle things in a project)

Priorities are about business need and how desirable a feature is.  A high priority means that the business really wants a specific feature and that they are (hopefully) willing to spend some effort and money on it.  A lower priority feature is something that the business can live without if they have to.

This has often been linked to working order, meaning that features should be worked in in priority order, from high priority to lower.  The reasoning behind this is often that if, for any reason, the project is stopped at least we have developed the highest priority features and therefore we can put those into use.

BUT (and this is where the confusion often occurs)

There could be other reasons for doing lower-priority features before higher-priority ones.

First, a higher-priority feature might actually depend on a lower-priority feature.  This means that the higher-priority feature cannot be developed or deployed before the lower-priority feature is in place.  In this case, it makes perfect sense to work on lower-priority features before higher-priority ones.

Second, resource constraints may push us to work on higher priority features before lower-priority ones.  Imagine we have 3 features, A, B and C which are prioritized in that order.  Furthermore we have 2 developers Albert and Cecilia.  Their respective competence areas mean that features A and B can only be developed by Albert whereas C can be developed by Cecilia.  In this case, it makes sense to do feature C before B, since Albert is busy developing A.

So, when we are talking about priorities, it would be beneficial for all parties to understand these complexities.  Otherwise we could end up PRIORITIZING features based on dependencies or resource constraints, which would be wrong.