Hi,
We'd like to be able to differentiate a Developer's work "done" vs. actual done-ness. We have workflow similar to:
To do > In progress > Dev Test > UAT > Done
Where:
How can we mark the Story Points as being "Done" (and therefore released) when Issues move from Dev Test to UAT?
Thanks
Nathan
I think you may be in a place where you have no clear consistent "definition of done", which generally will not work. But there are a couple of odd things in your bullet points which are unclear to me and I'd like to question:
I am going to assume you have one board that the developers are using to run their sprints. Given that:
My first question is the most important one - the column definitions. The later ones are clarifications, but their answers could be very useful in defining an answer.
Thanks Nic. Your response is both timely and informative.
To answer your questions:
Our ultimate objective is to be able to say to our Development Team Lead (me/my manager) "we've done this much work this Sprint" and not be held back by (understandably) less Agile parts of the business. We need to respect that whilst we're Agile, we aren't necessarily surrounded by Agile - well, not yet, anyway!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, great. Well, the only way to have a developer consider UAT done is to have UAT and Done in the Done column.
This looks confusing from the outside of the development team, but they're in a position where they can state that this definition of done is absolutely correct.
I would then use a Kanban board, with the same filter as the developer Scrum board, but with separate UAT and Done columns for the UAT people to track.
This will make your Scrum board give you the right reporting most of the time.
But as your UAT is outside, I would probably want to look at how it feeds back into your development cycle.
Re-opening a specific story is one way to do it, but it does feel unfair because your developers genuinely thought it was done, but had it rejected by someone/something outside the control of the team which causes your work to stop counting as "done". Ideally, the testing should be part of the Scrum, so "done" really is just "done", but I know that doesn't happen.
I usually recommend that defects are raised separately in these cases. Ideally as a new story that you will take into the earliest sprint you can, you don't re-open something you've delivered. If you're going to do that, then the developers should accept that all defects automatically outrank everything else in the backlog, so when you're building the next sprint, all of them go in. Your testers will have to accept that any defect raised will not be looked at until the next sprint starts.
This has some advantages - mostly, your Scrum team will start this with something like "assume 20% of our story points are going to come from the defects from the last sprint/delivery". You'll be able to refine that as you gather data from knowing how much you spend on real work and how much you spend on defects. It has a big benefit in measuring quality - if you can see story points on defects rising, with less and less development happening in a sprint, you can see you have a code quality problem - developers are turning out buggy stuff they need to fix later - you'll never get to 0% defects, but you should be aiming for it.
A bit more thought about reporting on it can also show you how well the testers are doing, even though you're not directly measuring them, and it can show that they might be a bottleneck, and maybe it's time to build multi-functional self-directed teams so you can incorporate testing and have a proper "done means done" approach...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Nic. Your pragmatic appreciation of the role of Agile in reality is appreciated.
I was feeling two Kanbans (one for Devs, one for Testers) is what would be required, and that defects should be raised in their own right, but it does feel incomplete in terms of SDLC.
Unfortunately we can't have the luxury of controlling inputs into our Sprints, we're mostly accounting for the quantity of the work we're doing at the moment within a busy environment. So asking users to wait until the next Sprint would be meaningless and possible offensive! We'd need to absorb them and allocate a percentage per Sprint for inevitable creep.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.