Our team has a wide variety of work item types. Some of the work we do is related to projects, some is operational, some we generate internally ourselves.

In order to be reactive to the needs of the business and other teams, we chose Kanban over Scrum.

Some larger projects are still managed in a waterfall manner. This is out of our control.

In these cases we start development and the stories related to the project transition through various states on the board, finally ending up in a UAT/QA column, where they stay before they get released to production at the end of the project. A project may last up to 12 months (or sometimes a bit longer). The result is we end up with a large number of tasks piling up in that column and they all get closed off/moved to Done in one go.

  • Do we need to alter our definition of Done to allow us to close these stories to prevent them piling up?
  • Do we alter the board, adding a new column to show a status of "Ready to Release". Not sure if this fixes the problem, or just moves it. If this is the answer, should this column be included in the cycle time? The project go-live date is out of our hands.
  • By stating the stories linger in a "UAT/QA" column, are you meaning that testing is also deferred until the story gets delivered to the client? Or is there a separate testing phase before that as well? – Bart van Ingen Schenau Jul 20 at 10:43
  • @BartvanIngenSchenau I mean that a story might actually be fully tested, and nothing else happens with it. But by the nature of waterfall, all of the stories go live only after the last one in the whole project has been tested. – Adam Rice Jul 20 at 15:14
up vote 2 down vote accepted

The kanban system should cover the part of the process that you and your team have control over. In your case, it sounds like it would start with the whole project's worth of work in the 'To Do' stage. You would pull individual tasks through the process over the lifetime of the project. It also sounds like you should have a stage after UAT/QA called 'Done'.

If you set a good WIP limit then, at any given time, most of your tasks will be in either 'To Do' or 'Done'. Only a small proportion of the work will be in progress. The advantage of this is that you can start encouraging a more agile approach onto your clients. If you let them review the tasks in the 'Done' stage as they're completed, the final handover won't contain any surprises. This will also give the client good visibility into the progress of the project. You should also let them make changes to the work which is still in 'To Do'. If they get into the habit of reviewing small pieces of work and then adjusting their plans, you're most of the way to convincing them to give up the waterfall approach.

  • 1
    Agree with @John_C. Very often when a client wants "waterfall" what they really mean is that product can be released only after significant functionality is completed, not earlier. But usually nobody objects from UAT of every completed portion of features -- i.e. you can establish usual Agile process, releasing not on production, but some staging environment, and ask your client to perform UAT there. In such case you will get most of Agile benefits, even if you can't get feedback from your end-users releasing on production. Also, related question: pm.stackexchange.com/a/24490/32641 – Anton Nepomnyaschih Jul 23 at 5:56

Unfortunately both of your proposed solutions suffer from the same problem: You never really know how much work is remaining on the 'done' items.

What happens if when you get to release some major issues are found? How long will it take to fix these issues? What about if a complete re-architecting of the code is necessary?

You talk about measuring the cycle time, but without knowing the work remaining on items the cycle time has little value.

For example, say the team makes some changes to the way it works and the cycle time improves. The team is happy that the changes are positive. Then, several months later during the final integration and release you uncover some problems relating to the changes you made. Now it becomes clear that the changes were negative.

You can tweak the columns on the Kanban board as much as you want, but with releases happening so infrequently it is going to be difficult to adopt a genuinely agile approach. Agile works best when there is a frequent inspect and adapt cycle that allows you to improve.

My suggestion would be to investigate if there are ways of doing interim releases or some kind of beta delivery. This at least gives you an opportunity to receive regular feedback and adapt your working practices.

A feature is done, when it could potentially be released to a customer. There may be good business reasons not to release it to the customer, but this does not change whether it is done or not.

So if it is ready to be released mark it as done. Track to see your revisit rate, if this is high, then re-evaluate definition-of-done.

As a separate project the business can look at inventory levels (done work, that is not being sold). Don't get involved with this, at this time.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.