A backlog of “bite-size” tasks in parallel to the “main” feature backlog?

After over two years of working in a highly siloed, “lone-wolf” development department structure, we’re adopting Agile SCRUM. Great. I like Agile; as a dev it keeps you focused, busy, and productive without having myriad stakeholders shoving project after project down your throat with the expectation they all be done yesterday.

There is, however, one aspect of moving to SCRUM versus our current “model”, that I think people outside Development are not going to like in the slightest. That is their current ability to have us do small changes “while you wait”. A large portion of our development is for in-house consumption only, and we’re mostly all in the same building. So, it’s been common practice for years for a department lead or manager elsewhere to come to the “codebase owner” of a particular application and ask for small stuff (sometimes not so small, but we’re pretty good about not taking on three-week projects based on these “drive-bys”). Even our boss sometimes relays things brought up to him in this way. Very often, if we’re working in the codebase in question at the time, we can simply pop up the source file, make the change, and run it with them looking over our shoulder to verify the change is what they want, before checking it into Subversion for inclusion in the next build.

With a basic Agile SCRUM methodology, these tweaks would either be logged as defects (we didn’t meet a requirement specified in a story previously consumed) or new small stories (we met all stated requirements, but those requirements were incomplete, vague or incorrect, or they changed after delivery once the users saw the new features). Either way, the vast majority would be one-pointers at most if not zeroes, and of relatively low priority (the system is usable in its current state, but it would be so much cooler if…), making them unlikely to be brought into a sprint when working the backlog top-down.

This possibility was raised at a dev meeting as being a source of active opposition to our Agile process by other departments, who would see it as less “agile” than our current ability to make small tweaks on request. It’s a valid concern IMO; the stakeholders behind the PO don’t always agree on what things are most important, because they don’t all have the same point of view, yet it’s typically only the managers who make the final decision, and therefore their bias is the one that shows in the product backlog.

A solution was then proposed, which was tentatively called the “candy jar” (another term thrown out was the “gravy boat”). Small tweaks requested by the “little guys” in the various departments, that are not defects in an existing story, that are estimated by consensus or acclamation within the team to take less than one-half of a developer-day, and that would have an immediate, significant, positive impact on the user experience in the opinion of the end user, are put on a list in parallel to the primary backlog. They’d be identified as “stories”, but would be kept separate from the primary backlog of “big” stories subject to prioritization. If, at any time during the normal progress of a sprint, we happen to be working in an area of the system in which one of these tweaks can be made, making the tweak trivial, we can bring the tweak into the sprint and code it alongside the larger story. Doing this must not jeopardize the completion of the larger story or any other committed work. The PO would also have access to this list, and if they were working on an upcoming user story touching the basic feature involving the tweak, they could fold it into the story as a requirement and then we’d meet the requirement as we would any other. This, it was thought, would make tweaks more likely to be worked on sooner than later.

This triggered the reaction among those of us with ScrumMaster training of “uh-uh”. There is one backlog. Two backlogs introduces the question of which #1 item is really the most important, which list’s items determine real velocity, and which of the two backlogs a story actually belongs in (any demarcation of size/complexity is going to have some cases that fall relatively arbitrarily to one side or the other). “Let the process work”, we said; if the change really is significant to the end users, they’ll make enough noise to get the department heads making time/money decisions on board, and it’ll get bumped up into the dev team’s consciousness toward the top of the backlog.

I thought I’d pose the question to the floor: In your opinion, would a parallel list of “bite-size” stories have value in getting small, useful but ultimately low-priority changes made faster, or is it overall a better decision to fold them into the main backlog and let the basic process govern their inclusion in a sprint?

I will talk about a few points which, hopefully, will help you find your way:

“SCRUM” is about being agile. Common sense is required. If the change is a few minutes change, I don’t think you need a backlog for it. If it’s more than 2 hours, I think you should give it a second thought. Not everything that is an “easy-win” should be done. In SCRUM you work by priorities. I think that the PO must get the information about what you gain from the addition and the effort it takes. Only then can the PO decide whether or not it’s important. Moving to SCRUM, sometimes comes with a lot of questions and developers will often say “but, that will only takeד a few hours”. So what? Few hours is time, not everything that is short needs to be included.
I once worked at a project where we had “engineering backlog”. This backlog contained items suggested by the developers for improving the product. Those items did not have an explicit user value (but did have an implicit user value). For example: refactoring a component in the code. We had described the change, the effort and the gain (in this case, you can’t present the user anything. But if such refactoring causes to develop new capabilities more quickly then it’s definitely a gain for the user). Our PO decided that during the version we should invest 10% of each sprint (in average) to such items. Before each sprint, when the PO decided about the upcoming sprint’s backlog, he made sure that we had 10% of enginerring backlog items. So 2 version backlog -> 1 sprint backlog.
Buffers – When starting to work in SCRUM people often forget that, as software engineers, we leave in a world of uncertainty. That’s ok to count 1 day of work as 6 hours instead of 8. Let’s say you have a 15 days sprint, that means you have extra 30 hours which go to meetings, to things that took too long, and yes – also for those little things that are too minor to remember but are a part of our day-2-day job.
Stay focused – Last but not least, in SCRUM it’s important to stay focused. Decide how much of your total effort, and what’s the priority, to invest in such tasks and remember to invest this time & effort. Don’t drift to work on “little things” just because they’re little. You have a PO to help you decide and you have your common sense.
Stay Agile – And, at the end, don’t forget to give a try to different methods to approach the issue, question yourself if that’s indeed the best way. Improve on the way.

Good luck 🙂

Programming frameworks like Agile and SCRUM are designed to apply discipline and structure to development. However, discipline and structure seem to be the antonyms of fun and creativity. Typically, you need to work harder to establish and maintain discipline. It is very difficult to find a balance between the these opposing concepts. Therefore, frameworks tend to avoid the topic.

On my last project, we observed that the developers needed a little time each day to refresh or clear their heads, etc. They were given budgeted time (.5 hours/day or 2.5 hr/wk) in which they could do anything, within reason (with the possibility of being applied to something at work). To keep things disciplined, they were asked to document their activities so they could get credit for any accomplishments, etc. Having a specific budget for “the candy jar” fit within our timelines and prevented things from getting out of hand.

Btw, we called ours “project coolness” and it wound up being the source of many good ideas and improvements at that company.

You should keep the small stories in the main backlog.

I face similar issues to what you are describing, although I am not using scrum. I see that you face challenges of prioritization and efficiency.

It sounds like under your “old way”, anyone was implicitly empowered to make their task the current “top priority” if they visited a developer’s office. This has some benefits. The requester feels like they are being responded to, and both requester and developer get a “quick win”.

The downside is that frequently inserting these tasks tends to slow down or derail the top priority tasks that were agreed upon with the product owner. (Side note, often everyone underestimates the amount of time needed for these “quick” fixes.)

My experience is that trying to squeeze in a low priority task undermines the benefits of prioritization. As a developer, prioritization validates to me that I am working on what the product owner wants me to work on. The product owner should decide whether she wants to take on the extra work and risk (however slight) of folding in a “nice to have” request.

Often when I ask stakeholders to prioritize, I am asked “Can you just squeeze this in?”. The implied wish is for me to magically complete the new task without impacting the current highest priority.

What often happens to me is that stakeholders request LargeImportantProject and SmallLessImportantTask. The dilemma is, should SmallLessImportantTask wait for LargeImportantProject to finish (or have a roadblock)? There are tradeoffs, and my experience has been that the product owner has to decide. (If the product owner does not decide, the development team has to guess.)

One goal of scrum (and project management in general) is to avoid roadblocks for the highest priority tasks. As you become more efficient, there is less room to squeeze in extra “nice to have” work.

The efficiency can be scary, but I have seen the benefits outweighing the cost in two important ways.

As you become more efficient, you increase your team’s capacity to complete valuable work, which includes “nice to have” requests.
If a request truly is a “nice to have”, it is probably perfectly legitimate for the request to wait until more important business priorities are addressed.

In my opinion; your problem is the way that tasks are prioritised in the backlog. For example, “priority” could take into account both importance and how quickly it can be completed. Something that isn’t as important but can be completed in 10 minutes can have a higher priority than something more important that will take several weeks to implement.

I’ve worked in agile for a while now. All I can say is this – there are situations where insisting on a methodology and all that it incorporates, is absolutely wrong. You have to be AGILE, and tweaking a methodology to specific situations is, IMO, a must.

Like Avi above said – “SCRUM” is about being agile. Common sense is required. If the change is a few minutes change, I don’t think you need a backlog for it.

If the change takes time, it means it is not all that “harmless” and it should be well documented.

Based on your initial question and subsequent clarifications, this is what I have perceived that your pain points are

Constantly changing requirements
Inability for developers to focus on other areas of the application, ie. we’re heroes on one part of the application but not
keen to touch any other.
Different approaches to architecture, solutions, frameworks being adopted
Requirements gathering process doesn’t seem to work

Scrum, if initially adhered to correctly should fix a lot of these issues, and more importantly, bring other issues to the fore that should be resolved.

– Constantly changing requirements

Having a single backlog that everything is fed into and prioritised correctly should mean that the team should not be bearing the brunt of requirements changing while in the middle of development.
If it is a very dynamic environment, smaller sprints of 1 or 2 weeks should ensure changing priorities can still be facilitated in a relatively short period of time.

– Inability for developers to focus on other areas of the application, ie. we’re heroes on one part of the application but not keen to touch any other.

A scrum team working well together and supporting each other, with a specific drive towards sharing knowledge within the team and looking for the challenge of working on other parts of the application will seek to ensure the knowledge of the application gets shared. Some practices like pair programming can help people overcome their fear of working on code they are not familiar with while also learning and sharing that knowledge. This may take a few sprints before the knowledge of the application is distributed between the teams and people are comfortable working on any area of the application. Also, allowing people to pull tasks of a board, i.e. make their own choice on what they would like to work, can encourage this.

– Different approaches to architecture, solutions, frameworks being adopted

Scrum facilitates better communication, it facilitates teamwork and better decision-making as well as providing greater visibility into what is going on. This is turn should facilitate the organisational decisions around the use of frameworks, architectural solutions, etc and the use of a Scrum of Scrums mechanism may help in instilling that throughout the organisation.

– Requirements Gathering Process

Again, if you adhere to rules strictly, if a requirement isn’t clearing specified and ready for the team to be able to understand and estimate what is required to fulfill the requirement, it should not be brought into the sprint. Take another requirement that is a high priority and has been well-defined… because then you know you will be able to deliver that! While it may not fix the requirements gathering process immediately, it will force the change required to get that process fixed.

To answer your first question, no, there shouldn’t be two separate backlogs. At any given time, it is in everyone’s best interest that the developers and the organisation are working on the highest priority items first. Priorities should mainly be based on business value, and it is quite possible many of the small tweaks and requests do add business value. Let the product owner decide that.

I’ve been a Scrum Master for over 7 years and helped with the introduction of Scrum into many different teams and companies. In my humble opinion and from my observations, I feel that if Scrum is being introduced into your organisation for the very first time, follow it by the book. Don’t deviate.
Scrum requires discipline to be able to stick to the practices and processes. It is too easy to make exceptions to fit certain circumstances, and if done too early, will lead
to the erosion of benefits and values it brings with it. Do the basics, do them really well. Become an expert at doing the basics and understanding why they are there, and then change the process to better suit and to drive continuous improvement within your organisation. Deviating from the basic processes and practices early on can be a mechanism to hide some other issues or the underlying problems existing in the organisation [probably the main reason why Scrum is being introduced].

There are very valid cases for saying this is “Agile”, so we must be willing to change the process, but there is a significant difference between a self-directed, self-organising team understanding the process and discussing changes that could be made to the process, as opposed to a team who are only beginning to walk down the path of Agile or Scrum. It’s like trying to run before you know to crawl…

Filed under: softwareengineering - @ 09:24

Thẻ: agile, feature-requests, product-backlog

Thiết kế website giá rẻ

Danh mục

A backlog of “bite-size” tasks in parallel to the “main” feature backlog?