Planning

Articles

Estimation questions Delivering Value with Agile and #NoEstimates

#NoEstimates is a challenge to the traditional thinking that estimation is essential to agile development. Ryan Ripley believes there are more interesting tools available to help us determine what value is and when we could realize it, while still staying aligned with the businesses and customers we serve. Learn some other ways to deliver value to your customers.

Ryan Ripley's picture Ryan Ripley
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
organizational structure Code Factories: Making Agile Work in Large Organizational Teams

Making the transition to agile can be difficult for teams that are used to working in large groups and reporting to a single manager. Kris Hatcher suggests a new way to work: in smaller teams called code factories, which are created to stick with a specific product throughout its lifetime.

Kris Hatcher's picture Kris Hatcher
truck overloaded and tipping Is Your Product Owner an Overloaded Operator?

Overloaded operators exist when an operator or operation has different meanings in different contexts. This usually applies to variables and sets, but it can be true for people, too. These people try to do the work of many different roles—and usually fail. If you have an overloaded people operator, analyze the work and try to divide it up.

Johanna Rothman's picture Johanna Rothman
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
shark Estimating Business Value in the Shark Tank

You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.

Allan Kelly's picture Allan Kelly
rising graph Plotting Data to Understand Your Agility

Many teams think they are agile in their projects, but if you're not receiving and analyzing feedback regularly, you're not really agile. Plotting the feedback you get on a chart throughout your sprints can help you see whether you have a lag. Read on to learn how to gather and use your feedback to be truly agile.

Mosesraj R's picture Mosesraj R

Pages

AgileConnection is a TechWell community.

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