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?

  • 6
    How well is the current cafeteria style of development working? If everyone is happy with it, and can live with the uncertainty of constantly-moving deadlines, then why adopt scrum at all? This is not merely a rhetorical question; the main reason you want to adopt scrum is to eliminate precisely that quality of your current development style that your stakeholders seem to value. You must be contemplating scrum because you perceive a problem that scrum will solve; has that problem been adequately and convincingly communicated to the stakeholders? Commented May 9, 2013 at 0:59
  • We have several problems with the current system; first, people that "own" the codebases of various in-house apps get buried by "drive-bys" requesting additional features. It's difficult or impossible to move on and focus on something else. That in turn basically makes each developer the "guru" for the code they have written, instead of each application being a team effort that every dev is at least somewhat familiar with. Not saying that any code ownership is bad, but strong code ownership, yeah we want to stop that.
    – KeithS
    Commented May 9, 2013 at 4:08
  • This system also largely prevents communication; we all each support the apps for which we're the ones still around who have done work with them, and we don't have time to learn what other people are doing. This has resulted in the adoption of different frameworks depending on what that coder's most familiar with, making interop between codebases a nightmare (and we live and die as a company on our skill in systems integration).
    – KeithS
    Commented May 9, 2013 at 4:11
  • Lastly, there are some things that just can't be done by one guy, no matter how good. We want to be able to leverage our entire team in a coordinated way on big projects instead of waiting months for one guy to get all the LoC typed in on our NBT. That requires a system that allows that kind of coordination without going through our boss for everything. Up till now we haven't bothered, even to the point of hiring new people for the sole purpose of giving them something new to develop and own.
    – KeithS
    Commented May 9, 2013 at 4:15
  • Oh, and lastly-lastly; the current system of requirements delivery is primarily these "drive-bys". If I happen to be elbows deep in a completely different codebase, and I don't write down what you want in enough detail to remember what you actually wanted when you came by my cube to ask me, it's just as likely to slip through the cracks entirely. Requirements gathering for larger projects is more organized, but there's always one more thing, and there isn't currently a central repository for these things.
    – KeithS
    Commented May 9, 2013 at 4:20

6 Answers 6


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

  1. "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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 :)

  • 1
    +1 for the engineering backlog. This could also be used for those user requests that otherwise don't ever make the cut. Commented May 9, 2013 at 12:15

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.

  1. As you become more efficient, you increase your team's capacity to complete valuable work, which includes "nice to have" requests.
  2. 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.
  • Good points. Contrary to the consensus so far, but that's why I asked the question; to get all the viewpoints.
    – KeithS
    Commented May 9, 2013 at 23:06
  • Everything Aaron says is true...but it all leads to "big company" dynamics. Too many hoops have to be jumped through to for the end user to get what they want. Thus, they will eventually stop with proposing the minor tweaks that end up with them getting a good tool and just use the "crummy" tool as-is.
    – Dunk
    Commented May 10, 2013 at 15:14

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.

  • 1
    This is a good point; "ROI" should be considered when setting priority. Do the thing that gets you the most improvement fastest. This can be encouraged when setting up the backlog (we're really early on in our Agile adoption).
    – KeithS
    Commented May 9, 2013 at 14:57

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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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