We talk a lot in our blogs about improving things and stuff not-to-do... But what about those who are at the beginning of a new project, creating a new backlog, working with a new vision and new stakeholders? How do they get started?
I get a lot of questions from the people I've trained and worked with over the years. Every now and then, a get a question that, as I read it, I realize actually gets asked a lot, even if in many different ways. Here's the latest:
"If my team discovers that they under-committed the Sprint and wants to bring in a new story (or stories), what should we do if the actual size of the story is less than originally estimated because we've learned more since it was originally estimated? And, if my team learned more, aren't we positively influencing our velocity without having actually solved that much more complexity? Wouldn't that be wrong?
In transitioning to Agile Development, many organizations suffer from the completely accepted but incorrect premise that coding tasks and testing tasks are and should be maintained as separate activities. In other words, designing solutions and writing code should be done by one part of the organization and the identification of test cases and the writing of test scripts (automated or manual) is performed by another part of the organization after the code is completed.
The results of the second “Sprints and ScrumMasters” Survey is in and, while we wouldn’t call the results surprising in any way, the answers do provide some interesting information about the challenges being faced by Scrum Teams and how they are electing to deal with them as well as some trending from the 2011 survey that might also prove interesting.