How to handle multiple stories with changes on the same big Cobol program/module in a Scrum Sprint without ending in a mini-waterfall at the end of the Sprint?
The risk is that the development sub-tasks of multiple stories are linked to each other, with 1 or 2 (pair programming) developers, and by this action all those stories are delivered at the same time. The result is a waterfall Sprint Burndown, and we want to avoid that.
-
are your stories actually stories i.e. if you only did one of them would it be demonstrable?jk.– jk.2016年10月13日 12:21:13 +00:00Commented Oct 13, 2016 at 12:21
-
Yes, I see what you mean. If you do them separately they are each one demonstrable on their own. But... the Dev Team states that it's not efficient enough to deliver them separately.Gunther De Cock– Gunther De Cock2016年10月13日 12:31:26 +00:00Commented Oct 13, 2016 at 12:31
-
It's kind of strange to see the words "Cobol" and "Scrum" in the same sentence. Good for you, being able to work in a sane process in (what I assume is) a legacy system!Jörg W Mittag– Jörg W Mittag2016年10月13日 23:07:39 +00:00Commented Oct 13, 2016 at 23:07
-
Always (or at least very often) the first answer I get, Jörg. But I'm still a believer that it is possible.Gunther De Cock– Gunther De Cock2016年10月14日 12:39:45 +00:00Commented Oct 14, 2016 at 12:39
1 Answer 1
Have you considered swarming? Everyone involved works together and there is little downtime from a development standpoint. Instead of various sub tasks in progress at once they are instead addressed sequentially within a sprint. This also breaks down knowledge and communication barriers.
Glad to see cobol and agile in the same sentence.