Vasco Duarte suggests that people should experiment with #NoEstimates to learn and find ways in which it can help them to deliver value on time and under budget. He is writing a book on #NoEstimates in which he explains why estimation does not work and how you can use #NoEstimates to manage projects.
An interview with Yaniv Yehuda, Co-Founder and CTO of DBmaestro, about how they are doing agile development and using DevOps, how they implemented continuous delivery, on agile practices that turned out to be difficult to implement, and the benefits that they are getting for using agile and DevOps practices.
Technique of "value points" to determine the value delivered by any software project.
Debbie Madden and Vasco Duarte share their views on no-estimates.
Matt Rogish talked about using Objectives and Key Results (OKRs) for company, team, and personal goal setting at the No Pants Festival 2015 in Antwerp, Belgium. InfoQ interviewed Rogish about what OKRs are and how you can use them, their strengths and pitfalls, doing annual performance reviews and managing people with numerical goals, and starting with OKRs.
This post covers the value of estimation in large and small scale projects and views on no estimation.
If organizations want to make informed management decisions to maximize the delivered value they will need to gather evidence about value says Gunther Verheyen. InfoQ interviewed Gunther about evidence based software management and finding evidence, how Scrum relates to evidence-based managing, challenges in scaling agile, and advice for enterprises that want to adopt Scrum.
There are different opinions for conducting sprint planning. Long debate is happening between velocity driven sprint planning and commitment driven sprint planning. Mike Cohn, founder of Mountain Goat Software, shared his views in his recent blog on Why I Prefer Commitment-Driven Sprint Planning.
Agile teams which use noestimates, can use slicing heuristic to empirically measure cycle time to help them predict how much, can be done before doing the actual work.
Agile teams measure the velocity of their sprints. It helps them to plan and track their progress and provides insight for product owners to plan product releases. Can teams also use velocity data when they want to improve themselves? Several authors have written about velocity and shared their concerns on measuring velocity to improve the productivity of teams.
A new "Scrum Kickoff Planner" has just been released by Adam Weisbart with the aim of facilitating team discussion around the important facets of starting a new Agile team or project.
In his recent blog posting “Planning Poker: Avoiding Fallacies in Effort Estimate” Hayim Makabee discusses a common problem of effort estimation called planning fallacy and why planning poker helps to avoid it.
Velocity, the measure of work completed by the team divided by the time taken to complete it, is increasingly being used to manage the productivity of a team and as a comparison between teams. Jim Highsmith, Mark Levison, and Scott Ambler discuss the misuse of velocity as a productivity measure.
There have been numerous attempts over the years to determine the best way to measure the effectiveness of an Agile adoption. Some recent articles have reignited the debate around the most useful metrics.
There have been numerous arguments and debates in the past on whether bug fixes should be counted towards velocity. There does not seem to be a 'one' right answer. However, Agilists have some recommendations describing situations in which they should be added, how they should be added and where they could be avoided.