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.
The debate over the value of Earned Value Management (EVM) and integrating it into agile rages heavy as agile penetrates into more large scale IT projects that require EVM. Opinions vary but some believe that not only can agile projects apply EVM; EVM with agile is better than EVM without agile.
Is slicing stories in horizontal tasks an Agile Smell? Is this common habit used in Scrum/Agile Planning meetings - hurting a team's focus on customer value? What is being suggested instead?
What is an appropriate Agile Metric? If traditional measures like: Earned Value, Hours Worked, Lines of Code, Code Coverage for Tests are not well suited to Agile Projects, then what is? What rules can we define that will help us choose good Agile metrics?
In a recent interview on Venture Hacks (Advice for Entrepreneurs) commentator Eric Ries discussed the concept of the Minimum Viable Product (MVP) – doing “just enough” to meet customer needs in order to get a product THAT PEOPLE WILL PAY FOR to market as soon as possible.
40 years after the NATO Conference on Software Engineering, Tom DeMarco paused to reflect on the discipline's evolution, wondering whether the metrics orientation he championed has distracted from the real point of computing: "transformation, creating software that changes the world." Is his earlier advice valid, though? "No", he said, in Software Engineering: An Idea Whose Time Has Come and Gone?
Tathagat Varma, general manager with a large provider of IT management solutions, wondered whether Agile's productivity improvements could be linked to how it improves teamwork. His article analyses Agile values and practices by mapping them against Patrick Lencioni's business fable "The Five Dysfunctions of a Team."
An implicit assumption made by most Agile teams is that 'value' is directly proportional to the 'velocity' of the team. While this may be true in some cases, however mostly, the team velocity gives little indication on the true value delivered.