Articles

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
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
Flow chart for an organization Realizing Value by Establishing an Agile Project Management Office

Some believe that an overarching organizational and governance model to structure operations in agile environments is needed. An agile project management organization can act as an aggregator and evaluator of agile project data metrics to help leaders track performance for improved value delivery.

Gail Ferreira's picture Gail Ferreira
Question marks Product Owner, Product Manager, or Project Owner?

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.

Charles Suscheck's picture Charles Suscheck
User story card User Story Heuristics: Understanding Agile Requirements

Agile emphasizes just-in-time requirements rather than upfront preparation. The requirements person—be it the product owner, business analyst, product manager, or someone else—embodies the understanding of what is needed, and the user story represents the work that needs doing. This article details what user stories are (and what they are not).

Allan Kelly's picture Allan Kelly
Stacked rocks: work not done The Art of Maximizing Work Not Done

One of the twelve principles behind the Agile Manifesto is “Simplicity—the art of maximizing the amount of work not done—is essential.” Why is this principle called an art, while the others aren’t? And why should we maximize the amount of work "not" done? This article analyzes the importance of simplicity in agile projects.

Ledalla Madhavi's picture Ledalla Madhavi
Clock: ready for go-live Are You Ready for Go-Live? 8 Essential Questions

As real and daunting as scheduling pressures can be, they have to be balanced with the consequences of a potentially disastrous premature go-live. Don’t let all the reasons a system simply "must" be implemented by a target date overwhelm compelling evidence that it is not ready. Consider these eight questions honestly first.

Payson Hall's picture Payson Hall
Drive Product Delivery Taking Vision to Reality: Using Agile to Drive Product Delivery

Product development organizations that skip or rush through critical preplanning activities run the risk of failure. Organizations that use a more agile approach to product development ensure that the teams work on the right things, have the right amount of dialogue with their business partners, and produce the right amount of value to the product.

Jack Walser's picture Jack Walser
Agile Planning The Five Levels of Agile Planning

Contrary to popular belief, agile projects require as much planning as any other project type. It is the timing of this planning and how we attempt to minimize wasted effort that is different from other approaches. This article attempts to explain the different levels of agile planning and how we utilize them in an ongoing project.

Paul Ellarby's picture Paul Ellarby
Delight Your Customers Excite and Delight Your Customers by Using the Kano Model

Chandra Munagavalasa writes that because the requirements change over time, the product backlog is never complete. As the project progresses and more detailed information becomes available, the product backlog items and their rankings change continually. One of the many techniques available for ranking the product backlog is the Kano model.

Chandra Munagavalasa's picture Chandra Munagavalasa

Pages

AgileConnection is a TechWell community.

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