In my last Scrum article; SCRUM-tastic Tuesday - Dealing with naysayers; I talked about common complaints heard when trying to employ the Scrum process. As I mentioned, those types of comments are not really unique to Scrum and are often heard when trying to implement other processes by those that don't feel they need any process. There was one question that I purposely left out which requires some dedicated focus.
This work is too large to fit in Scrum.
This brings up a couple separate issues... "push-back" and managing individual backlog items that are spread across many Sprints. The push-back is easily dealt with, by using a little common sense. The naysayer is attempting to suggest that large projects cannot be accomplished using iterative or Agile processes. Assuming they can say that with a straight face, any experienced manager should see right through it. Just take a look at any Gantt Chart for a typical waterfall process and the non-sense should become evident. Even if the decision to use Scrum vs. some other process is open for debate, this line of thinking is a slippery slope and often leads to cowboy-development initiatives which can easily fail, fall behind schedule, exceed budgets, or miss customer expectations entirely.
At the risk of sounding redundant, Scrum strives to have its participants set a short-term goal (e.g. the commitment), allow it to happen, and then retrospectively assess what they have done. This frequent repetition allows its participants to make minor; even major; course corrections based on their experiences throughout the life of a project. But what about larger architectural considerations? Good question... Just because you're working in short iterations does not mean you can't work from a larger architectural plan. Adherence to this plan is left to the Product Owners (or architects) to ensure backlog items are prioritized appropriately before each planning session.
If you're working on a big project you may find that you have backlog items that are either so large they can't be accomplished in one iteration, or represent work that applies to every Sprint. These situations are actually very common in Scrum and have many names (e.g. Epic's, Saga's, Enterprise Stories, etc.). Requirements surrounding compliance with specifications are a common example of this. If you've developed e-commerce sites you may have had to comply with things like PCI, Section 508, OWASP, and others. There is a tendency to make these types of things backlog items although I think this may be a mistake. Generally speaking, backlog items should represent "what" the customer wants. These types of requirements are really constraints on "how" it will be implemented. This may seem like splitting hairs but there is a reason for this line of thinking.
The problem (or at least concern) is backlog overload or making the "process" become the product rather than focusing on prominent features. If Product Owners keep presenting the same backlog items over and over again, these items can take valuable time away from consideration of more substantial feature-sets during planning sessions. This can start to turn into white noise, and pretty soon no one is really paying attention. I'm not suggesting specifications aren't important, I just think they should be planned and dealt with in a different manner. I like to think of them as "constraints" rather then backlog items. These are things that shape "how" the developer will implement "what" the customer needs. Constraints are a natural part of defining "what" is needed, so it shouldn't seem strange to add them to a given User Story.
This is a bit Freudian, but the goal here is to keep the main focus on the larger User Story as apposed to any one constraint and the smaller the number of stories in planning the more effective your meetings will be. To make up for any concerns related to not making specs a first class backlog item, try making your specifications a focus-area in your test plans. This gives you visibility into overall compliance and will be a continued reminder for everyone involved.
No matter how you decide to manage such requirements, these concerns are not really unique to Scrum, or any other Agile process for that matter. With that said, the Scrum process does provide a framework which may just make it easier to manage within your team. If nothing else, these considerations may just help you do a little push-back of your own on those naysayers.