Articles

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
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
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
Agile: yes or no? Agile or Not? Asking the Right Questions

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?

Adrian Wible's picture Adrian Wible
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
Balanced scale Relieving Agile Tension: How to Write Small Stories That Still Have Value

There are two practical goals for user stories: Each story should be beneficial to the business, and each story should represent a small piece of work. However, there is tension between these rules, and they often push in opposite directions. This article discusses how to keep stories small and tasks manageable, while ensuring they retain business value.

Allan Kelly's picture Allan Kelly
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
Burndown chart Help Your Team Understand Its Iteration Burndown

A good key indicator for measuring how well your agile team is performing is the burndown chart. It’s a simple concept—as time passes, the amount of work to do decreases. Of course, there will be days when progress is not as expected or tasks end up larger than originally estimated. A burndown can help your team reset and keep stakeholders in the loop.

Dave Browett's picture Dave Browett
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

Pages

AgileConnection is a TechWell community.

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