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 …

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 …

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.

In this blog post, Pawel Brodzinski discusses the problem of the Product Role in Scrum teams. It is not always possible of having a client representative working closely with a project team. So the team should sometimes find other ways to get answer questions about the product and fill the product ownership activity. His conclusion is that knowing what is important to build is the essence of product ownership. A good Product Owner is only one way to achieve this objective.

In this blog post, Matt Archer shares his definition of the Agile Test Lead role and what he thinks they should contribute to Scrum teams. He says that behind the practical aspects of the Agile Test Lead role, there are also subtle connotations of coaching in this position. In his opinion, it is this coaching element that makes many Agile Test Leads valuable for the Scrum team they belong to.

Thom Roach shares with us in this blog post the metrics that he includes in iteration summary reports. The three main statistics he uses are Iteration Statistics summary, Iteration Cumulative Flow and Team Velocity Chart.