Testers who analyze quality in every aspect of the team’s deliverables also have a responsibility to mitigate risks and practical issues that are bound to come up, and help the team succeed in their product as well as at being agile. Here are five such issues that testers can help the team alleviate or avoid.
If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.
The daily standup, or daily scrum, is a short meeting the team uses to briefly communicate work commitments with each other. Dick Carlson answers some questions that agile teams, management, stakeholders, and those who are thinking about transitioning to agile commonly have about these daily standup meetings.
Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.
As agile principles and practices receive greater organizational exposure, business teams are embracing certain aspects of agility that were traditionally reserved for technology teams. This article details the experiences of a group of people with business roles who have adopted some agile methods and how their teams have benefitted.
In this article, a developer shares his personal experience with the transition from a waterfall environment to an agile one. He compares what it was like for him coding, learning, and communicating using each methodology, and he shares what it was like making the change to agile—and why he's never looking back.
Effort estimation is a major challenge for all the stakeholders of a project. Most people generally underestimate situations that may block progress and consider only the best-case scenario for a project. Your choice of estimation method may not be helping, though. Which would be better for your team: estimating by man-hours or by user story points?
Of course, all companies would like to reduce their budgets. But cutting back in the IT department can have unintended consequences. This article looks at two of the more well-adopted cost-cutting approaches, the software factory and distributed teams, and goes into how they can help and hurt your company.
Teams should be working toward a target velocity that is based on historical evidence. There may be times when this figure needs to be adjusted, but teams that understand their velocity know that it is a good indicator of what they are capable of achieving in a sustainable way, and this will increase confidence for the teams and stakeholders.
The #NoEstimates movement isn't really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?