Instead of choosing what to develop based solely on a cold, hard dollar amount, you might try approaching the person who originally requested a story—or who will be most affected by it—and asking, “What benefit will this bring you?” Armed with a list of stakeholders and interests, you can find out the real difference a story will make.
For many, pair programming delivers benefits such as increased focus, improved team relationships, and better code. Tom Breur and Michael Mahlberg found that pair writing can work, too, and the advantages bear a lot of resemblance to those of pair programming—more concentration, productive feedback, and better writing.
Gil Broza's book The Agile Mind-Set: Making Agile Processes Work speaks to the challenges faced by people who focus on "doing agile" rather than "being agile." Rote execution of methods can only get you so far, and Broza gives insights into how you move beyond practicing agile by habit into living it.
Many agile practitioners recommend re-estimating stories at the beginning of each iteration to increase accuracy. Adrian Wible, however, argues that re-estimating stories within an iteration planning meeting actually distorts results and decreases predictability. See if you need to rethink your planning procedures.
Many organizations dipping their toes into agile just want to know one thing: Are we agile or not? Most agilists agree, however, that rather than a binary designation, agile is more of a continuum. It's a sliding scale that can vary across the development lifecycle. A better question is: How agile are you?
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.
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.
Too many user stories begin, "As a user …" Who is your user? Or, more accurately, who are they? Improving your understanding of the types of customers who use your software lets you see multiple products where previously, there was only one—and identifying dedicated products will help you prioritize and accelerate delivery.