|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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?
|
|
|
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.
|
|
|
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.
|
|
|
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).
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|