Make Scrum dogma your own. Take what you need, leave what you don’t. Here’s one more option to add to the article’s list.ScrumMaster™ gives you the option in a Retrospective to take credit for work completed in the sprint. It automatically renames the remaining tasks and returns them to the Backlog… ready for evaluation at the next sprint planning session.
No, this isn’t orthodox Scrum procedure. But it makes sense, doesn’t it? It cleans up reports, too.
Sometimes we need help to improve our team and sharing insights into why some practices and behaviors can sabotage team progress. Take a look at the following observations teams have made to see if your team can identify with them and take action before it becomes a bigger or longer term problem.
We have a lot of stories that are closed by DEV and then new stories for QA testing are created to test what Dev hands over.
Impact to the Team:
- Because the number of stories in the sprint steadily increase during the sprint, the burndown chart will likely look like the team is always behind schedule.
- Individual capacity is extremely difficult to plan during sprint planning because the number of stories at the beginning of the sprint will be lower than reality.
- Forecasting sprint plans and project schedules via velocity is useless here because the…
View original post 988 more words