A pity, as real life means to do Roadmaps and planning further ahead that 2-3 Weeks. Please reconsider.

Thanks

The strength of Scrum (and as I understand, all agile project management practices) is to optimize the value of the releases. If you fix features for the next releases, maximazing the value is impossible.

I give you an example: In an non-agile project you present a fixed roadmap to your client with Stories A and B. A is palnned for release 1 and B for release 2. Now in the first sprint the development team completes 90% of story A and says that the last 10% will be very expensive, since they did miss a detail which was not specified exactly. Now your 2nd sprint starts and you have to finish A, before starting B. Result is that you will miss your deadlines for both releases.

In Scrum, you can change the the priorities after the first sprint. Your PO or client decides, if completing the last 10% of A is more valuable or if starting B is more valuable. Or perhaps you have to create Story C which replaces the missing 10% with an other solution. Perhaps B has to change completely because a new solution D replaces everything. The value of the solutions decides, not the roadmap.

Scrum means, that the value of the outcome of the next sprint has priority over any roadmap. If you work in an company which has decided to give guarantees of specific stories for multiple future releases, I don't see how you can do real Scrum. And Kunagi is not the right tool for you. You should consider using some other "Scrum" tool which also allows doing "Scrum"-like processes. Kunagis distinguishing feature is to do strict Scrum only.

You are correct in defining SCRUM and agile the way the theory is meant.

The way we use SCRUM and Sprints is we collect Stories that fit thematically. eG. One Sprint is about all things green, the next one about all things blue etc. Then we can setup a product roadmap that says we will deliver green stuff, blue stuff, yellow stuff and so on.

Kunagi looks very promising as a tool, better than most others I've tested until now, and I like what I see. Concentrating on strict SCRUM theory makes for a very narrow scope, but I'll have to live with it, as I'm not a developer and could not schange the code if my life depended on it.

Kind Regards
Aleks

Thank you for the feedback.

Here is one more thing, how Kunagi "supports" roadmaps. When you have a product backlog with all top stories estimated and you set the Assumed Velocity at the top of your product backlog, Kunagi shows you which story will be completed after 1st, 2nd, 3rd... sprint when nothing changes. Perhaps this is all you need?

Witek,

thanks for thinking with me.

Unluckily, here we adhere 100% to Scrum and only estimate Stories in the Sprint Meeting that are highly prioritized _for_that_Sprint_ by me as PO. It would drive the developers crazy if they'd have to estimate all 2-300 Stories in the Product Backlog, and doing it up front would be of no use, as the lessons learned during the Sprint and in the Sprint Review would change the estimate anyway.

Maybe I'll set up the "Roadmap Milestone" as a theme an can filter that way for the Sprint meeting at the beginning of a Sprint. Anyway it's a pity I can plan Releases up front (as many as I want, as far as I can see) but not Sprints.

Thanks
Aleks

Hi Aleks,

thank you for your feedback.

As Witek said, there is a projection in the Product Backlog based on velocity. I understand that developers wouldn't want to estimate hundreds of Stories up front to allow projection. But how would you pre-plan Sprints if you don't have estimations? That is one reason why we do not plan multiple Sprints ahead.

Hi Artjom,

there seems to be a slight misunderstanding here. I do not want to plan the precise content of the Sprints by any means, but I'd like to plan the overall direction (what I defined as colors) and if possible the timescale. Red in this Sprint, Blue 3 weeks later and so on.

I agree with you planning the precises Stories that should go into the Sprint more than one Sprint ahead would go contrary to what Scrum does and is mean for.

But I can plan releases ahead, without filling in the Sprints. Maybe a similar thing should be possible with Sprints, without filling in the Stories?

Kind Regards
Aleks

I see what you're up to. Have you tried creating releases (under Product > Releases) ahead? You can later link them to your Sprints.

Hi Artjom,

yeah, that's the solution I've used for now. But of course releases are a different beast, as normally you wouldn't release after every Sprint, but after some number of Sprints.

Kind regards
Aleks

On my best running project we have multiple releases per sprint. Our client gets changes every two or three days, so we get immidiate feedback. We have branches for every new feature and when something is stable we merge it to master and release. This works so well, I would do this on every project if I had the chance.

Hi Witek,

I guess we all leave the clean theory of Scrum from time to time to fit the reality of our surroundings. Pragmatism has always been a good idea.

Kind regards
Aleks