3

currently we are having the following states/columns in JIRA:

  • Open/Todo (-> Developer takes task and starts work)
  • In Progress (-> Developer sets tasks to done)
  • Done (-> QA tests on staging and sets task to ready to deploy or reopens)
  • Ready to deploy (-> Developer deploy these tasks at date of release)
  • Deployed (-> QA/Stakeholder tests task again on Live/Production and closes or reopens)
  • Done/Closed

In my current understanding this is wrong, because we try to handle two concerns in one status dimension: Development and deployment. I would like to decouple sprint from release/versions. Currently we cant end a sprint until all tickets are approved on production which leads to bottlenecks.

What would be your suggestion? One idea I have in mind: Limit the status to Open, In Progress, Done, Closed and handle the deployment/release over JIRA build-in versioning. If a problem occures on production, a bug ticket must be opened.

Otherwise I don't see a chance since the versioning/releasing of JIRA 6.4 does not seem to include status columns by itself.

Cœur
  • 37,241
  • 25
  • 195
  • 267
SBehn
  • 73
  • 7

1 Answers1

1

Is releasing to production part of your team's 'definition of done'? If it is then the workflow you have makes a lot sense.

There is no separation of concerns between development and deployment. Code that has been developed but not deployed has no value to the business. Development is simply a step in the process towards release, which is the point at which value is realised.

A sprint is a timebox, not a set amount of work. When the timebox ends then the work that you have still in progress is not 'done'. If you are regularly unable to complete all the work you bring in to a sprint then that suggests you are bringing too much work in. The team's velocity, which is a measure of the work that gets 'done' each sprint, should be a good indication of what your sprint capacity is.

If your bottleneck is the release to production and verification of the release, then perhaps you should focus some effort on improving this process? Possibly this could mean more release automation or better coordination with the stakeholders over validating releases.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • Thanks for your answer. But isnt it wrong to have dependencies outside the actual scrum team? I would definitely say, the stakeholder is not part of the scrum team. The team cant commit to something which is out of their scope. On the other hand, I wouldnt want to hand over all acceptance resposibility to the QA team inside the scrum team. Any thoughts? – SBehn Jun 08 '15 at 07:49
  • The ideal is for a Scrum Team to have everything they need to deliver. This is not always possible, so we attempt to minimise external dependencies. Few Scrum Teams eliminate all external dependencies. The issue with handing acceptance over to QA, is what happens when bugs are found? You will need to bring those bugs back in to the team. Plus, studies have shown that it is efficient to fix bugs soon after the original work was done. Handing off to QA risks bugs being worked on weeks later. Better to schedule acceptance testing in the sprint and work on any bugs as and when they are raised. – Barnaby Golden Jun 08 '15 at 11:58