3 ms·
> every sprint we either fail to deliver the work we commit to Stop committing to so much. > deliver work that ultimately fails the QA process Stop committin
by epicureanideal 6y ago
> every sprint we either fail to deliver the work we commit to
Stop committing to so much.
> deliver work that ultimately fails the QA process
Stop committing to so much.
> half the team is quite junior
Stop committing to so much.
I see you tried that, and Parkinson's law got you, but it might be that the team needs several sprints to catch their breath and also change the way they work.
> people seem to indicate everything is fine until 3-4 days before the end of the sprint
Sounds like they are afraid they can't be honest. There's something going on there.
- tunesmith 6y agoJust for a short term experiment, you could shorten the sprint to 1 week.
- Falkon1313 6y agoSure, that would be revealing at least. 2 days to get ramped up, update tooling, dependencies, database snapshots, docker containers, etc. Do all requirements gathering, investigation, and design work. 2 days for code review, testing, handling bouncebacks. 1 day to deploy and do retro. Oops. Forgot to allow even one single day to do the actual development part of the work.
- tunesmith 6y agoOne of my teams did one-week sprints and it wasn't as you describe. If that scenario is true, then the one-week-sprint did its job - it exposed the problems that need to be solved. That's way too heavy of a tooling/process burden.