When applying an Agile mindset, you should consider the value of each task that you are asking the Agile team to complete. Agile often brings value concepts into play and determining the value of tasks is one way to achieve this. Is the task you are asking the team to do considered value-added or non value-added. Sometimes folks have a hard time wanting to separate tasks into value and non-value because it highlights the non-valued tasks folks are doing. However, if you really want to know, then you must do this (typically at the Product team level).
Keep in mind that in Agile, value-added tasks refer to only those tasks that are directly related to building the product and that your customer values. This would primarily include user stories and the attributes of this work related to the “done” criteria (e.g., incrementally designed, developed, built, tested, etc.) in order to complete the user story. On the other hand, non value-added tasks are those tasks that do not contribute directly to building the product. This may include administrative related tasks, training, all-hands and other status meetings, writing status reports, spending time on correcting defects, tasks related to correcting technical debt (like refactoring), and other tasks not directly related to building the product.
A good practice in Agile (e.g., value capture metric) is to capture all related work a team does in a sprint (as backlog items) to understand what are really value-added tasks vs the other tasks that we do. For each story or backlog item, assign it an attribute of either “value-added” or “non-value-added”. You can track this on a sprint basis (or release basis) or trend it over time (from sprint to sprint). Below are some examples:
A good practice in Agile (e.g., value capture metric) is to capture all related work a team does in a sprint (as backlog items) to understand what are really value-added tasks vs the other tasks that we do. For each story or backlog item, assign it an attribute of either “value-added” or “non-value-added”. You can track this on a sprint basis (or release basis) or trend it over time (from sprint to sprint). Below are some examples:
Chart 1: Value of work per Sprint (can be rolled up to the release level)
Chart 2: Value of work per Sprint (at the detailed level)
Chart 3: Value of work from Sprint to Sprint (Trend line)
The big advantage of this type of metric is that it helps you 1) be aware of the value and non value related work that your team is doing and then 2) it allows you to make adjustments if you want to get to a more value-added stream of work. While this may force you to make some tough decisions (what is value-added and what is not), it will be worth it in the long run to get your team more productive and focused on the value-added work for your customers. This can help you on your Agile journey!
Hi Mario,
ReplyDeleteI don't entirely agree. A task that you'd consider non-value, such as refactoring, is actually a task that does add value to the customer, though perhaps not in a visible way, or perhaps not immediately.
For instance, even making a progress report adds customer value, in a way. In doing so, the partner or manager in charge is kept updated on project status, and may eventually conduct a corrective action that adds value to the customer or the product (to avoid delays, improve project quality, etc.)
A task that does not add value to the customer (directly or indirecttly, immediately or not immediately) should not be done at all.
Maybe we could distinguish 'direct value-added tasks' versus 'indirect value-added tasks'. But I'm afraid that this may backfire: if you value more the 'direct value-added tasks', then you may relegate important tasks as refactoring or bug fixing because they don't add value directly.
Kind regards,
Daniel
dzacharias@hexacta.com
Hi Daniel, Thanks for your comment. In general, value-added tasks are those that directly build functionality to your product. Non-value added tasks do not mean the tasks are un-important, but that they do not directly add to functionality. As you pointed out refactoring can improve the product but sometimes it is a result of sub-optimized work in the past which some would consider rework (e.g., refactoring changes technically should not show any customer facing difference in the functionality). The focus though (of this entry) is to consider the relative importance of the work we are asking the team to do and recognize that some of it does not directly build the product and some is less value work that others. This way it provides awareness and then provides us data points for us to then do something about this (should we wish).
ReplyDeleteRefactoring is not related to technical debt but rather is the mechanism by which iterative design is done.
ReplyDeleteFurthermore - I think you may have employed some dangerous terminology. "Valuable" is a very loaded word. Perhaps instead you can refer to activities that directly result in new functionality as simply that - "Functionality-related-activity". When you call it "Valuable" then the tendency is to "Maximize Value" - ie: minimize activity that do not result in new functionality. But this "Functionality-related-activity" is extremely tactical - it focuses only on the functionality delivered today. The problem is that a team's effort to improve, to experiment, to innovate or to strengthen its capability is strategic and leads to long-term gains and would fall into your "Non-Value-added tasks" and would hence be minimized - after all, why would we do something that does not add value?
I appreciate the intent but I think the oversimplification is dangerous.
Giora Morein
gmorein@bigvisible.com
Hi Mario,
ReplyDeleteI agree with Giora here - I can imagine a C-level manager being shocked by the graph you outlined and immediately reacting with "Well make them do less tests!", without understanding or wanting to understand the impact.
If you ask a team a closed question such as "are you spending time building value?" or even categorizing work as either adding or not adding value, most likely the team will just hide away anything that is considered "non-valuable" regardless of the fine-print.
Once you acknowledge that anything they are doing adds some value (this takes trust), the focus can be shifted to the type of value gained.
With one team I worked with I once collected and reflected to the team themselves how much time they were working on adding new functionality, how much time on refactoring and how much time on test-related work (writing tests/manual testing).
The focus again was on what value they gain from each type of activity - coding obviously adds features to the product, refactoring is an investment in future team-speed (since it's easier to make changes to clean code than it is to smelly code), and testing makes sure there are no bugs.
With this focus and set of metrics, the team had realized they were spending a lot of time refactoring and testing, and came to a decision to limit - or budget - the time they would spend for each type of activity. In further sprints we monitored how this was going, reflecting and fine tuning in each sprint, and looking for ways to improve - for instance using test-first approaches and increasing test automation to reduce time spent on testing activities, or just limiting the refactoring and setting explicit clean-code criteria (which can otherwise become a never-ending adventure).
In this manner the metric helped the team take responsibility for their time and find ways to improve.
So all in all it's a question of how you interpret the metric, who you show it to and for what reason.
I look forward to reading your next posts, as always you've written up on a not so obvious topic, definitely worth discussing.
Avi
Yes, some folks do not like having perceived value items called non-value. However, we need to remember that value is from a customer perspective first and foremost. And also this implies that we are utilizing the "Done Criteria" when building the functionality, ergo adding appropriate long-term stability and quality. While many of the non-value added tasks that I indicate has some value, it is important to separate customer perceived vs engineering perceived. I have found this metric to be very valuable so that teams understand that a percentage of their velocity isn't really building functionality. This is not necessarily a bad thing but it removes the false pretense that we are focus 100% on building functionality. If you choose to use other words that is fine, but I suggest that there is a significant difference between building functionality meeting done criteria vs working on other engineering tasks (refactoring, escaped defects, etc). Also, this metric is meant for the team level so it is not intended for upper management.
ReplyDeleteStill, the feedback you are receiving here is valid, if you are able to hear it. I agree with the previous posters, and would add that "defect-related work" is also certainly providing value that is directly related to functionality.
ReplyDeleteThe danger in classifying effort like this is that stuff you classify as "non-value" starts to be seen as "overhead" which can possibly be reduced or eliminated. Thin ice.