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?
Usually noise has a negative connotation, but in this sense, noise means something that increases the team progress (i.e., velocity) and output (i.e., quality). Chaos is the negative side of noise and decreases velocity. Teams should know the importance of agile noise and handle the chaos in a right way at the time of transformation. Let’s explore agile noise and its benefits.
Of course, all companies would like to reduce their budgets. But cutting back in the IT department can have unintended consequences. This article looks at two of the more well-adopted cost-cutting approaches, the software factory and distributed teams, and goes into how they can help and hurt your company.
After performing so many meetings at the ends of your sprints, agile retrospectives can become monotonous and boring—and that’s when they become ineffective. This article looks at the reasons this happens and provides some ideas for making those retrospective meetings more lively and effective—and therefore more useful.
Teams should be working toward a target velocity that is based on historical evidence. There may be times when this figure needs to be adjusted, but teams that understand their velocity know that it is a good indicator of what they are capable of achieving in a sustainable way, and this will increase confidence for the teams and stakeholders.
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?
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?
There has been lots of talk about the “agile mindset,” but what does that mean? It does not merely encompass the skills that make a successful agile team member, but rather what drives a person to want to be part of an agile team. It should include the quest to learn (even when you fail) and leveraging what you learn to continuously improve on what you do.
Feedback loops serve as opportunities to increase productivity, either in an individual’s performance or in project teamwork or process. Identifying areas for improvement throughout each sprint and turning them into action items can help you track and address the key challenges related to technology or product improvement.
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!