Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.
share|improve this question

3 Answers 3

up vote 5 down vote accepted

I've been pushing for making these tasks into official user stories, but no one else seems to like this.

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.

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?

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,

Refactor redundant (across multiple projects) code into independent libraries - could potentially be used by many projects.

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.

share|improve this answer
    
You raise some good points. These tasks don't really need to be user stories, but they do need to be in the backlog so they can be picked up, tracked, etc... I think the problem that I'm running in to is a reluctance to add anything to the backlog that is not a formal user story. –  FrustratedWithFormsDesigner Feb 18 at 19:42
    
This answer matches what I was going to write. Our backlog contains many developer-only issues that get prioritized like anything else in the sprint, so that we do not have a bunch of technical debt floating around. Some of these are written by the dev team as they see fit to add them, and some are written by me as they get mentioned. If there's an internal need for everything to be a formal story, then try using "the system" as a user... (I'm not a big fan of story format for its own sake). –  jcmeloni Feb 23 at 17:10

Thanks for an informative question - for someone like me who has never formally used Scrum as a method for software development. I am part of a product company - and we went from traditional waterfall to Iterative to what can best be described as Kanban - altho' Kanban by itself is not a software development method.

I am not trying to "sell" Kanban to you - having been around for over 25 years in the software industry, I am very familiar with the challenges involved in changing processes in a software organization! But I thought I'd share ideas from Kanban which you might have the flexibility to try in your team.

Kanban's key points are to visualize your existing process, limit work-in-progress (limit WIP), establish Pull and improve gradually (evolutionary change rather than revolutionary). Since you are already practicing some of these, the rest might be easy to adopt.

We have - and had - a very similar situation to yours - lot of regular feature development and defect fixing work as part of the regular product enhancements, that needed to go out in a release; interspersed with code refactoring and other Engineering driven tasks - and our challenge was visualizing it for everyone in the company so the CEO and Sales and Marketing knew exactly how much work Engineering was handling, and allow them to weigh in on the priorities of all the work.

When we moved from an iterative process to Kanban, within a couple of iterations, our board looked as shown in the pictures shown below -

Our Dev process was mapped in the Dev lane of the Kanban board - enter image description here

Our overall Kanban board looked like this, with the last lane being reserved for Engineering driven and other 'hygiene' work - enter image description here

As you can see, we not only had a Dev lane and a Global/ Engineering items lane, but also some customer interrupts and a planning lane. Each lane also specified how much total work could exist in each lane - the WIP limit for that lane. Developers would take up (pull) work in the Global task lane whenever they had any spare capacity. Once they pulled it, they would typically finish it before taking on a new user story.

This allowed us to map and visualize our situation exactly as it was - whether we liked it or not, a high-priority customer interrupt did delay or shift work on other items. Instead of trying to map them as user stories, we mapped each type of work as is - and pushed work out to Staging and Production as it became ready. The normal process we used was to include some of the engineering stories/ tasks ever 3rd release or thereabouts.

The beauty of this system was that it helped us study the volume of work in each category (Kanban calls it "class of service") and reorganize our board, our process, and the team as we went along. Within one year of adopting Kanban, we made a production release almost every month - which made our Sales and CEO - and our customers very happy of course! And of course, doing this meant that we automatically had 'official sanction' from the CEO and Product Management - recognition that this work was important (but not necessarily urgent) - and needed to be done whenever there was spare capacity available to do it. Of course, there were times, when with the help of Prod Mgt, some of this work got specifically prioritized due to its urgency.

So, if possible in your environment, I'd suggest that you have a frank discussion within the team - and with any stakeholders that need to be involved - and work out a method that helps you map your current work and process - and helps you arrive at agreement to prioritize some of this work on a regular basis - and package them in the first possible sprint/ release that you can. In the process, you might find yourself doing somethings that are not necessarily "true to Scrum" - but might help you evolve to a better process that allows the team to work much more smoothly than it perhaps might be doing today.

Apologies for a long response, but I hope it helps. And again, this might not be a direct response to your question - but I hope some of these concepts might be useful for your situation.

share|improve this answer

The way I've solved this issue in the past is to just have fun with it. Make them user stories. Who's to say what user is actually defined as in that sense?

As an old-timer project, I want to build with Maven, so that I can be built in a single step and better manage my dependencies.

I think this is the best way to solve them. A huge benefit is that this way it still makes you ask, why?

Why do you need to refactor those old projects?

The why is important for the POs / PMs to actually justify these tasks, and in my opinion, gives your team a valuable insight into these tasks.

YMMV, but I like this approach, and it has worked for my past teams.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.