P = Product value
B = Bug fixing value
A = Architecture value
R = Robustness value
There are many different ways to measure the productivity of your agile teams, but certain measures get typically forgotten but they are ultimately why you are doing the work in the first place.
That's why I thought of this measuring system called P-BAR.
P for Product value and it is purposely the first letter. This is what ultimately matters. This is what your end customers benefit from. In a perfect sprint, you are always adding a lot of product value. However, the real world is not perfect and that's ok. It is ok not to have a lot of product value in sprint 0 and 1. But later you should be having sprints with the P value high.
Bug fixing value makes sense after you some number of P-value sprints and now functionality is being tested, and it is ok to have some percentage of bugs being fixed. However, if you are adding a lot of B-value in the 11th hour of the project, then it means you left all your bug discovery and/or fixing for late in the game.
Architecture value within your sprints may be high at the at the beginning sprints and occasional sprint later, but you should question it if too much of this being added closer to the end of your releases.
Robustness value measures to what degree you are developing your code to the enterprise level. This is something that should be evenly distributed throughout all sprints. It should be part of the culture and not something being done at the end.
In this article I will not get into how you measure this. You will somehow measure each value for each sprint and you can use it to detect if you are heading in the right direction and you can also capture trends/averages for overall release. At some point, I will write a full article about this.
Thank you,
Almir Mustafic
No comments:
Post a Comment