Planning

Articles

Model airplane Build One before Building Many: Learning from Agile Feedback

When you're working on a project and are presented with a big story or requirement, resist the urge to treat it as a single piece of work. One of the principles of the Agile Manifesto is to deliver working software frequently. This allows you to learn from what you built and make adjustments. See if you can break down the request and find a small piece of work within the big.

Allan Kelly's picture Allan Kelly
Clock Estimating Cost of Delay in Agile Projects with Time-Value Profiles

The cost of delay for releasing a product can be due to many factors, but that value loss can seem like an abstract concept. Attaching hard numbers to a release timeline in the form of a time-value profile helps the development team and business stakeholders have a conversation about how long they have to build a product and when it would be best to enter a market.

Allan Kelly's picture Allan Kelly
Transparency The Transparency Experiment: Improving Accuracy and Predictability in Scrum

Using the iterative and incremental agile development framework Scrum should help manage product development, but some teams still have difficulty delivering features in a predictable manner. This organization decided to address the mismatch between what was being committed and what was accomplished by doing an experiment in work transparency.

Tape measure Estimation: What It Takes to Deliver Consumable Value in Agile Projects

Releasing in small batches is a good way to achieve quick feedback in your sprints, but these pieces don't have all the features users need. Providing consumable value is turning those small bites into a meal, and it’s worthwhile to estimate what it will take to deliver that—asking, “What consumable value do we expect to achieve, what duration and cost should we plan for, and how likely is it that the plan will succeed?”

Andy Berner's picture Andy Berner
Releasing SMURFS Instead of MVPs, Maybe We Should Be Releasing SMURFS

The term minimum viable product, or MVP, has come to be misunderstood and misused in many organizations. It doesn’t mean you should be releasing half-baked, barely feasible software. Instead, you should be thinking of your product’s capabilities as a Specifically Marketable, Useful, Releasable Feature Set—or SMURFS!

Matthew Barcomb's picture Matthew Barcomb
financial graph How to Train Agile Product Owners Using Financial Terms

Prioritizing stories for an upcoming sprint can lead to confusion and miscommunication between the product owner and agile teams. But putting that exercise into financial terms, such as purchase, budget, cost, and investment—a set of words that everyone understands, no matter what their area of expertise is—gets everyone thinking about value.

Kris Hatcher's picture Kris Hatcher
caution sign Proactively Planning for Risks to Your Agile Project

Being aware of risk is good project management common sense. But to address risk quickly and effectively when you encounter it, the best method is to establish clear, agreed-upon, communicated responses to risk before it even happens. Dave Browett suggests some tactics to mitigate and confront risk you can use with your team.

Dave Browett's picture Dave Browett
money and a clock The Effect of Time on Value in Your Agile Projects

Using effort estimates as the only criteria for deciding whether work is undertaken could be leaving money on the table. Considering value—in particular, the effect of time on value, as in whether there is a cost of delay—makes for more intelligent conversations and better decisions.

Allan Kelly's picture Allan Kelly
Santa checking list Would Santa Claus Make a Good Product Owner?

The elves working on Project Santa—you know, the big delivery that happens every December 24—have decided to go agile. But Santa, the product owner, is busy and not always available to answer questions or provide guidance. What kind of suggestions and improvements should they address in their retrospective?

Dave Browett's picture Dave Browett
pots of grass Stop Re-estimating Your Stories for Every Iteration

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.

Adrian Wible's picture Adrian Wible

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.