Companies have reported that focusing on things that make their employees happy can give benefits. But how can you measure and analyze employee happiness? Some insights in the why of happiness, and the results and lessons learned from those who used it.
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.
Good measurements support good management. So what metrics should be sent up through the management chain so management can best support Agile software development processes?
Does a the traditional Sprint Burndown chart help the team? A number of Scrum teams find that tracking task hours hides the true state of the sprint and prefer other tools.
The traditional agile approach to prioritization is that user stories of higher business value should be implemented before ones of lower business value. The concept is simple, but implementing it well relies on having a mechanism to assess business value. Pascal Van Cauwenberghe has recently described an approach to defining business value, called "Business Value Modeling", which may help.
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?
Traditional software development teams were supposed to work within the confines of the software 'Iron triangle'. The three sides of the triangle are Scope, Schedule and Cost. Jim Highsmith suggested that the Iron triangle, imposes a lot of constraints on the flexibility of the Agile teams and suggested an alternate Agile Triangle.