Hi, in our retrospective in the OPS week we were talking about staying on topic in the sprints. The rational is that if we make the sprints to huge we never get something useful out to the customer. And that is the most important because that is the major way to get feedback and contributions. So here is a nice example of how we should not blow up our tasks, and this is not to blame the squad but to illustrate what I mean. Yesterday I talked to Darix about the state of the Umbrella Sprint. On the whiteboard I read things like "Investigate social media stuff" and "implement a key-value storage" and such. This tasks should not be part of the umbrella sprint. Of course they can be useful, yes, there is potential that if we use a framework that can we safe work later etc etc. - all granted, but still: No. Off topic for the umbrella sprint. Go the direct way and get stuff out the door. Make stuff even more cool and efficient etc. in later steps/sprints. Simply create new sprint proposals for these things. So what is the umbrella-sprint than? Good question, and I see it in the responsibility of the squad to define that. Try to answer the question "When is the project considered successful?" and write the answers down and start an open discussion around it. This list should answer the question when the sprint is finished and avoid them being infinite. That should be the first step actually, and I want each of the squads to come up with a few lines of specification what the current sprint is about and what not. AI Squad Leads: Have this little spec for the current sprints ready in Wiki by next sprint meeting (tuesday next week I guess). Again: This is not to blame the umbrella squad but this was an example jumping in my eye. We're all one mischpoke. Yours, Klaas -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org