"converting" tasks to stories
Hi All,
My squad for the past 3 months or more, have not been working on stories at all. Most of the sprint work includes spikes, discovery, tasks for documentation, environment configurations, environment creations, automation. Where I work, they don't want tasks to be pointed, only t shirt sizes. This means that our metrics are not showing the work we do, they are not showing our capacity, velocity etc. One suggestion was to maybe use stories instead of tasks when for example they need to create an environment. So that we will have some metrics to show to management and we can better plan our sprints. We do however meet our sprint goals and we don't carry tickets over, unless, our developer is being pulled out of the sprint by engineer leads, (thats another discussion for another day ) . I always explain to management why we dont have metrics and what actual work we do so far they seem to accept it but I don't want to get to that stage where they will pressure me cause we all know how much management likes metrics and number.
So would this be a good idea that some tasks to be converted to stories or raised as stories, even though they are only for environment configuration/creation and not work to actually create a value a user can use. Thanks
This is my opinion so don't assume this is "the answer".
My first piece of advice is to forget about tasks, stories, epics, etc. No where in the Scrum Guide does it mention any of these. The Scrum Guide describes Product Backlog Items. One category of "things" that are all treated equally. Estimation is not a requirement for Product Backlog Items but it is a useful practice for many teams. The estimate is useful for the Developers to decide if they can complete a body of work during a Sprint timebox. After that the estimates are worthless for any type of metrics. The simpler the Product Backlog is organized, the easier it is for everyone.
Second piece of advice continues on what I said about estimates. Do not attempt to evaluate your capacity, velocity or anything else based upon estimates. That is like trying to evaluate the distance your car can go based upon the number of boxes you think you can fit into the back seat. One has nothing to do with the other. I argue that you can provide some useful metrics if you look to flow metrics such as throughput or cycle time. But even then, those metrics are useless for measuring the value of what is being delivered. And that is the goal, to consistently deliver usable increments of value in each Sprint.
...they will pressure me cause we all know how much management likes metrics and number.
As a long time member of "management, what we want to see is that the money being spent is producing something that can lead to enough money coming in to sustain the organization. The number of tasks being completed is useless because it doesn't tell us anything. A task can be defined to mean anything. For example, a task to update the configuration for an environment means nothing. The benefit to updating that environment does especially if it can be tied to the value the company or end user will realize.
I always explain to management why we dont have metrics and what actual work we do so far they seem to accept it but I don't want to get to that stage where they will pressure me cause we all know how much management likes metrics and number.
Isn't there a Product Owner who can help by clearly accounting for Product value?