Blogs on Scrum and Agile Project Management
This is an on-going series of blog posts that want to answer the classical question: How is software testing done during Scrum sprints? In the first installments, Clemens Reijnen discusses the importance of having testing knowledge in the team and implementing a collaborative culture. He then presents regression testing, test automation, end-to-end testing, avoiding overlapping tests, product backlog item implementation sequence, risk and business driven tests, writing acceptance tests. Microsoft Visual Studio is used as an example of tools supporting software testing practices in Scrum sprints.
Martin von Weissenberg explains in his blog post that focus and rapid feedback not only improve software development projects but shorten them dramatically as well. He use an experimental setting to compute the ROI for four different approaches: traditional plan-driven project delivering near the end, an unfocused project with continuous delivery, a focused project with an 80/20 Pareto distribution of value and a focused project with an 80/50 Pareto distribution of value. The results prove that focus and rapid feedback in the form of continuous delivery are game-changer.
What should be the lenght of a Scrum sprint? There is no unique answer to this question. In this blog post, Mitch Lacey provides some key factor to consider when you try to choose the right sprint length for your Scrum project. These should be considered looking at the expected duration of the project, the customers/stakeholders and the Scrum team. His conclusion is that the right sprint length balances a craving for customer feedback and input with the team ability to deliver and the customer’s ability to respond.
How do you manage activities that don’t seem directly related to features in your Scrum sprints? This blog post discusses why it is a problem when Scrum teams start to wonder about having time to manage infrastructure, technical debt or test framework. For Johanna Rothman this is the sign that the culture is not Agile enough and that the product owner doesn’t want to take iteration time to schedule anything other than features in an iteration. She offers seven hints on how to improve this situation, saying that product owners that don’t want to fund technical debt will instead create more of it.
Analyzing the bottleneck faced by a Scrum team, Mark Levison introduces in this blog post the concept of Skills Matrix. The Skill Matrix is a visual management tool that shows at a glance how much cross-training you have in your organization between different people and different tasks.
The “rightsizing” of user stories occurring during the planning of the next sprint in Scrum is not always an easy task to perform. Inexperienced teams have difficulties to split user stories into smaller chunks that still deliver business value and would rather use technical criteria. In this blog post, “Specifications by Example” author Gojko Adzic provides a new approach to achieve this goal using the hamburger as a reference. You identify the tasks making up a user story. Then you use this breakdown to identify different levels of quality for each step and create vertical slices to identify smaller deliverables, thus creating your next sprint’s hamburger.
The Scrum Daily Stand-up meeting is certainly the most regular team activity in agile software development projects and there are therefore many material available on how to manage it and prevent it to become boring, useless or both. In this blog post, Anders Laestadius provides four ideas to improving the daily Scrum meeting.
