We have a number of tasks that need to be completed, but are probably not real user stories, or if they are, they are very developer-centric user stories which will never be visible to the end-users. The problem is that because they do not get estimated as a part of a sprint and very little gets done on them. Eventually, it becomes enough of a problem that someone takes time out of a sprint to deal with them, but that affects progress on "official" sprint work, which makes some people a wee bit unhappy.
I've been pushing for making these tasks into official user stories, but no one else seems to like this. How else could I request official recognition for these tasks, so I can allocate full days on them without feeling like I'm affecting the rest of the sprint?
Some examples of the tasks, just to give you an idea:
- Write small, custom maven plugins to simplify specific (and widely used, within the organization) build configurations.
- Refactor old project(s) to build with Maven and newer tool set.
- Refactor redundant (across multiple projects) code into independent libraries – could potentially be used by many projects.
Best Answer
An important question to ask / answer here is - do these tasks need to be user stories, or do they just need to be in the backlog, given the same consideration as user stories? I'm not a fan of writing a task as a story just for consistency, as (imo) the purpose of a user story is focus on delivering value to the customer by developing to a customers action. At the end, the customer can test against the user story.
Conversely, a developer task often doesn't need a user action to be tested (e.g. refactoring a large class files into multiple, smaller class files), and it doesn't need to be in a user story to be understood by developers. IMO, keeping user stories and developer tasks independent allows you to track how much time your spending on delivering direct customer value.
But that's probably beside the point, and I'd ask if the real issue is getting management to sign off on project maintenance / improvement tasks? If so, you may need to change your focus slightly.
The key here is to justify their need. Having a centralized, accepted build process is a very standard Agile practice with very obvious benefits. It will improve productivity and developer engagement, and reduce integration costs.
Conversely,
requires some justification as to its value (buzzword there was potentially). If there's real use - e.g. there's duplication between projects - show it. Show the commits that were made. Show the stories they were tied to, and how having to write a routine multiply, maintain it multiply, etc - leads directly to increased time to production.
Refactoring is an important part of professionally handling code. If I can't regularly spend (small amounts of) time refactoring, then the code is on a downward spiral, and I'm looking for another job. Simply put, when you can't expect to refactor code, you're forced to spend excessive amounts of time with up-front architecture considerations (you break the YAGNI rule). If I trust we can re-visit modules in the future to improve them, I can focus on the delivering the simplest working solution possible and getting immediate user feedback.
Developer "stories" matter, and deserve a place in the work-flow. Whether or not to formulate them as a User story is subjective, but don't let that be the focus of the discussion. Get them into the workflow, then worry about how to label them.