|
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.
|
|
|
5 Ways Testers Can Mitigate Practical Risks in an Agile Team Testers who analyze quality in every aspect of the team’s deliverables also have a responsibility to mitigate risks and practical issues that are bound to come up, and help the team succeed in their product as well as at being agile. Here are five such issues that testers can help the team alleviate or avoid.
|
|
|
Defining Acceptance Criteria for Agile Requirements Acceptance criteria can be helpful in expanding on user stories in order to capture requirements for agile projects. However, acceptance criteria should not be a route back to long, detailed documents, and they are not a substitute for a conversation. This article tells you how and when acceptance criteria should be written and employed.
|
|
|
Stories, Epics, and Tasks: Organizing Agile Requirements Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.
|
|
|
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.
|
|
|
User Story Points versus Man-Hours: Estimating Effort Better Effort estimation is a major challenge for all the stakeholders of a project. Most people generally underestimate situations that may block progress and consider only the best-case scenario for a project. Your choice of estimation method may not be helping, though. Which would be better for your team: estimating by man-hours or by user story points?
|
|
|
The Case for #NoEstimates The #NoEstimates movement isn't really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?
|
|
|
How Do Your Estimates Provide Value? If you are agile, you might spend some time estimating. If you’re using Scrum, you estimate what you can do in an iteration so you can meet your “commitment.” But estimation is a problem for many agile projects. The larger the effort, the more difficult it is to estimate. You can’t depend on ideal days. Do your estimates provide value? To whom?
|
|