Welcome to 2020 🤖

Good luck! Small, fast sprints make great sense to me. Trust your team to handle their work, make sure everyone has free time to refuel, especially you, and test out new features and ideas with the community frequently instead of doing big, dramatic reveals. I think the development will progress better with lots of quick steps instead of a few giant leaps.

Toadsith

100% agree with this.

Toadsith

Frankly I think you need to start small. Make an estimate of what you think you can accomplish in 2 weeks, then cut it in half and add some smaller tasks as 'extras' that you'll work on if you finish the others. One constant 'extra' would be reviewing what is already done to see if it still jibes with the current direction/state of the project and looking for bugs. Basically your eyes are bigger than your stomach. I think you're always going to dream too big for these things and need to reduce the tasks in either number or size or both. Not give up on the grandiosity, just look for ways to break the bigger (and not so bigger) tasks into smaller steps

bsnick

I think what you are missing is a scrum master or project manager that absorbs all the organisational work. You are managing people, projects, and still contributing to sprint work. Even when I shave worked in small teams the team lead only did maybe 30% of the amount of sprint work compared to others. You should expend more time upfront to plan even if that means no obvious output for a few sprints.

Ano123

As mentioned by someone previously, sprints revolves around tasks delivery if you focus on features or releases tied to a sprint you are setting yourself up for delays. This is because for agile methodology you are supposed to release even if you failed to finish all planned tasks for the sprint and during reflection understand why did you fail to achieve the tasks. A task can be "updating 5 stories" or "fixing this bug"

Normally SCRUMs daily standups with the team, should be enough for you to recognize that some planned feature won't be finished at the end of a sprint. The core idea is it to cut the features in tiny tasks of work, which may take 1-2 days at most. That way you see after a few days already if there will be a delay, since after each day some tiny part of the feature should be done. Noticing right at the end of the sprint that the goal won't be meet is a clear sign that your tasks were too big and you couldn't reflect on it on a daily basis. Of course separating a feature into really small tasks, is quite some overhead, since it requires you to be able to judge each tasks really quickly and put them in a sprint and then cut them down into tiny tasks before the sprint starts. Maybe "hardcore" SCRUM also isn't the best way to organize your work, since the big selling point of SCRUM is, that you can plan your work and features rather consistently over the whole time and react to tiny changes your client wants rather quickly... while at the same time telling your client directly how much you can do and when something will be done. If that isn't an important thing for you, maybe something like Kanban or other variants of agile might be better.

Sheol

Never did get comfortable with agile development buzzwords. Set realistic goals. Don't make yourself sick over arbitrary deadlines. Get out in the fresh air, have fun, eat and sleep healthy. Your customers would prefer honest delays due to unexpected complications in the work instead of failures in the project methodology. Use the old NASA trick of Plan For Success by setting realistic goals and allowing for Murphy. Did I mention setting realistic goals? Take care of yourself, this should be fun!

Fritz T Coyote

Why does it have to be a sprint? It is stressful and I don’t think that’s constructive imo.

FRsinewave

To be honest I wouldn't advise that. The huge majority of teams working on SCRUM or Kanbahn use the 2 weeks sprints and that's because it's a better way to structure the work you'll be doing over that period. The further you extend it the more likely is that your plan for that sprint won't reflect the amount of work you can actually undertake during that time. In my opinion Crush should maintain the 2 weeks sprint schedulewith realistic goals regarding what can be achieved during that time. Also, he should avoid getting stressed if sometimes he's not able to finish all the planned tasks for a given sprint, since that's actually something natural to happen once in a while. The main thing here is, if this becomes a regular thing, then he needs to review his planning schedule because he'll be clearly over planning. As I've already said previously, Sprints should be focused on tasks, not releases. If a release takes 3 or 4 sprints, that's fine, it's how actually most teams work. One of the projects I work with took 14 sprints to get a release and no one panicked or stressed, because everybody knew that was the time it would take to get the release of the planned features done.

xgrotesc

A comprehensive analysis is a good way to eradicate errors and develop improvements. I think your idea of exchanging the two-week rhythm for a goal-oriented person is very good. Depending on the size of individual areas, the duration of the sprints would always have to be defined individually. And one thing should be clear to all of us, not every successful sprint goal justifies a new publication at the same time. Here, too, it is now necessary to find an appropriate balance between when releases take place. In the first place, nothing should be rushed. My recommendation, take the time of the sprint goal, try to stick to it and then hit again 10-20% of the time for tests before starting a devtest.

Falloutbabe

Also you can adjust, if two weeks is too fast, you could make it three or even monthly. I think what matters most is that progress is actually progressing. None of us expect you to always make a goal. We all struggle with that whenever creating something that also involves learning and adjustments to implement the way you want to see them. And sometimes it may not look like what you want, and you just have to let it go for the release to get the feed back to grow closer. What matters is just staying in communication, recommitting and making updated time frames that make sense and actually work for you, your schedule, your team, the community, and are realistic.