JIRA rewrite
Posted on March 5th, 2010 by Stephen Hurn – 6 CommentsAs alluded to in Adam’s recent post on the next steps in our Agile journey we have taken the liberty of reorganising our JIRA workflow to better suit our new practices. We want to use JIRA as much more than a simple job tracking tool and begin using it much more as a part of both our organisational memory and as a key part of our work flow. I had also been getting irritated at the large number of useless or redundant jobs in the system. Thinking back on it now, I realise that the irritation was my brain sending me a signal that our processes were not alligned with our work flow.
When Adam and I sat down and were trying to work out the best way of using JIRA, we asked ourselves two questions:
- How do we come up with our new features and products; and
- If we did not already have JIRA, what would we like a tracking tool to do for us?
We ultimately came up with a rather simple workflow. We were quite happy with our use of JIRA for support tracking purposes and are not going to change that. So the changes were more for our product development cycle. Previously we had not been including user stories properly into JIRA and the way that JIRA was configured, our natural product development cycle was not taken into account.
The beginning of our process is what we call an “itch”. An itch is anything that may one day be turned into a product or part of our products. It may be as simple as a question “why does it take us a day to do this task?” or it may be a statement “our customer has said that they are confused by this button”. Itches are effectively our stimulus material. Paul added a job into our system a long time ago. The job was quite simple. It merely said “add bids”. As anyone in software development knows, sometimes the easiest things to describe are some of the most difficult to implement. In Agile terms, this job was an epic (actually it was beyond an epic, it was really what we call a legendary). Today this job would get logged as an itch. It is stimulus for us to create solutions from. Anyone can create an itch.
An itch has one of two states - itch and scratched. A “scratched” itch is an itch which has been satisfied in a product release. For an itch to be scratched, we need to create one or more solutions to scratch it.
A “solution” is our term for user story (one word being easier than two). The product owner is responsible for it, but it is owned by the whole development team. Estimates on solutions are what is used to determine velocity and which features are developed. More than one solution may be developed for an itch and one solution may scratch multiple itches.
The workflow for a solution involves several stages.
- The first is when we work out whether or not we are going to develop our solution further. If we decide not to do the solution the developer or product owner or whoever has made the decision will choose the “We have not decided to do this” option. If we decide to go ahead with the solution then “We will think this through in more detail” is chosen.
- At this point the solution will be fleshed out and an estimate made on how long it will take. “We have not decided to do this” is still a valid option at this stage. Once the job has been estimated and selected as a feature we wish to develop “We will do this” is chosen.
- It is at this point that the developer(s) will take the solution and turn it into code. “This is ready for testing” and “We have decided not to do this” are the options available. I feel that it is important to clarify that the testing referred to by this job is to ensure that the coded solution matches the business requirements. Automated tests are to be written and performed on code during the development work.
- Once the work has been tested, you are given the choice of “This has failed testing” to send it back to the developer(s) with a stern “tsk tsk” and a good finger wagging. Otherwise the user can progress in one of two ways - to a documentation step (if necessary) or to completion.
- The documentation step, boring though it be may sometimes be necessary for some jobs (e.g. a new database was created on a dataserver somewhere may require some documentation as to where the dataserver is and any relevant usernames and passwords).
As a part of completing any solution, a number of jobs may be created. A job is simply a task that the developer sets for themselves to do as a part of the process of completing a solution. It is totally owned by the developer(s) who are responsible for it and is only created to serve the technical component of a solution. It has a testing step (if the developer wants - it can be skipped) and allows estimates. A solution may have many jobs or no jobs, dependent on the developer involved. Jobs belong to solutions.
Outside the main development stream of itch -> solution -> job we have derived three other job types. Bugs, errands and rewrites.
A bug is simply a technical description of a problem that a user has. It allows estimates and has a similar workflow to the “job” described above. However a bug is a standalone job that does not need to be linked to a solution or an itch. It may be linked to a support issue.
A rewrite is a job type which identifies an area of code that needs to be rewritten to reduce technical debt. This type of job is owned completely by the development team, though the product owner is involved in prioritising when it comes time for iteration planning. Rewrites are not linked to any other issue type.
Finally, errands are jobs which describe tasks that need to be done. An errand may be something as simple as “send an email to these clients” or “change the password on this dataserver”. It is a catch-all issue type for anything that is not properly covered by the other job types.
We would love to hear any thoughts that others (particularly outsiders) may have on these changes.
Hey Paul,
As you say, that irritation is cognitive dissonance caused by doing things one way and knowing they should be done in a different way. The important thing is to capture all the inputs of work so that, when you categorise and push things into a workflow or process, you are not missing items.
To explain: your staff will have a certain number of things that they do, and having some of them organised still leaves some disorganised. Where I am, we have
- client projects work
- support work
- internal work
- personal items.
You need to be able to manage all of them from one place, whether or not they are corporate; then all of your decisions at a personal, management and business level are always made properly, and also they system/software captures those decisions as they are made, so you avoid double entry.
Hope that’s useful.
Thanks for your comment Chris, it reinforces what we were trying to do with the system.
By the way, I, Stephen wrote that post :).
Thanks Chris,
If I am interpreting your comments correctly, what you are talking about goes way beyond our current use of JIRA.
For instance, at Beer O’clock today we talked about our need to make a record (in one place) of promises made to clients, in order that we can track when we have delivered on each and every one (another post about this coming later). Some of these might be not related to individual products.
I have not specifically looked, but am not sure if JIRA would even cater for being used in such an all-encompassing way (i.e. extending far beyond bug tracking into business process management).
Something for us to investigate further a little later down the line.
I suspect we might run into the old “form over function” resistance, were we to try to use JIRA in this manner.
Cheers
Paul
Hey Paul,
yes, it’s quite a common problem, and I couldn’t comment on JIra of course without knowing it better. The great majority of businesses miss it, and the time of the team and the information is spread across different systems. This results in a flawed decision making process at the individual, team and organisational level; a lack of cohesive management information; double or triple entry; time wasted on overlapping work (not just tad entry); tasks missed or not considered; the list goes on.
It is not an easy problem to solve in a large organisation takes years. Our current systems are disparate, with client projects, support and other tasks being isolated. I am currently putting into production a system that has all these areas integrated, which will see our efficiencies improve substantially.
To scale an organisation successfully (ie still making a profit and all the staff being happy rather than stressed), systems and processes need to be aligned before expansion; otherwise costs become prohibitive. It seems that GR spend time considering the next steps, which is extremely positive, as there is a much greater likelihood of making the right sorts of decisions in this area.
Chris
That’s true, whoops
Just a couple of small notes:
The “documenting” stage for Solutions is primarily about documenting the details of a new feature or improvement on our portal. It fits in with the philosophy that a solution isn’t truly “done” until the portal reflects it. Saving details of passwords / how things work is of secondary importance, and really only need to be added if it “helps us go faster” in the long term.
The other thing to note is that we are now recording tests to perform within the Jira jobs themselves. Which is helping significantly in the specification and verification of work.