|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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?”
|
|
|
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!
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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?
|
|
|
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.
|
|