Let me explain our situation. We are small company with about 20+ staff and all the while we have been practicing the standard waterfall model with not much success (due to frequent changes of requirements and lack of direction).

So one day our CTO came in and he briefed us about SCRUM and all of us were convinced that this model will work great for a small team like us. Unfortunately all of us do not have any experience practicing SCRUM and we have been relying mostly on online resources and books.

Then we come to a new project that we are about to get started and we are doing something like:

  1. Gather requirements from business domain user
  2. Prepare a requirement spec with UI and features (this already took us like weeks)
  3. Meet up again business domain user to see if there is any changes required
  4. Once the business user agrees to the specs we will key in those feature in to product catalog
  5. Break those features into tasks and assign to sprint

Should we instead take the more agile approach? like

  1. Gather requirements from stakeholders
  2. Start to create epic user stories and run through with stake holders
  3. Break those epic stories into smaller stories (supported with some ui) and assign to a short sprint(2 weeks)
  4. We show them what we have done for the 2 weeks, get their feedback and plan for the next sprint

Given the nature of our projects where we are constantly faced with the challenges of volatile requirements and a lack of direction, where will the above Scrum/Agile points benefit us and why are the above Waterfall methods failing us?

  • 4
    -1 Your question basically boils down to the question, "should we use Scrum?" Commented Jun 6, 2013 at 15:33
  • 2
    you seem to be answering your own question: agile methods were invented precisely because it is very hard to do a requirement spec right, and it is also very hard to get a client to understand it - they will sign it off based on their own interpretation. Then you show up with your software and it is not what they wanted. The agile approach forces the client to engage with you, your understanding of them and your software as early as possible. So, you are basically saying yes, we should use agile. What is blocking you? Commented Jun 7, 2013 at 11:55
  • @WalterA.Aprile The problem was for method 1 we are doing big design upfront but in step 4 and 5 we do have things like product catalog and sprint(Which we assume we are doing scrum?). We just not sure if this is the right way to go to scrum, seems to me we still can't shake off that big upfront design practice in waterfall In fact 1 of my colleague even suggest to take some part of SCRUM and customise it to fit to our way of doing things which i think is not the right way.
    – CliffC
    Commented Jun 7, 2013 at 13:50
  • 1
    What makes you think you have the expertise to customize Scrum before you have even tried it? Commented Jun 9, 2013 at 11:42

3 Answers 3


The second approach is much more in the spirit of agile/scrum, but it also requires a commitment from the customer to visit regularly to see the progress and discuss further features.

If the customer is uncomfortable with such a commitment of effort on their side, or if they already have a very good idea of what they want to have, then your first approach might be more constructive.

One of the key points of scrum is that the customer gets a big say in the order in which things are produced, so let them clearly indicate which features they would rather have sooner and which features might end up in the bin if the budget gets too stretched. And don't kick up a fuss if the customer changes his mind on some requirements/stories, especially if they haven't been implemented yet.

An alternative approach, in a more scrum-like manner, but similar to the first approach, is like this:

  1. Gather requirements
  2. Split requirements into stories and put them on a backlog
  3. Start first sprint with stories "create architecture" and "UI proposal"
  4. During the sprint, discuss your proposals with the customer
  5. Refine the backlog
  6. As each sprint ends, pick the next top X stories from the backlog to implement.
  • 1
    not to pick nits but "create architecture" is not a story in the usual sens of user story. Stakeholders don't need to/are not able to understand system architecture. Architecture is what you as a developer do to make the stories happen. Commented Jun 7, 2013 at 12:00
  • @WalterA.Aprile: You are right that neither of the first two are typical user-oriented stories (neither of them creates something directly usable). IMO it is still best to have an outline of the architecture before starting with the real stories, so why not do that in the first sprint. Commented Jun 7, 2013 at 15:57

The main advantage of SCRUM (and agile methods in general) is that you get better and quicker feedback (on implementations, not just specs) from the stakeholders, and thus there is less risk of working weeks and months on something that ends up being not what they wanted. Additionally, you often deliver the most useful features sooner (due to prioritization and the sprint release cycle).

If you all agree that you will benefit from these advantages, and if the stakeholders are willing to do their part (give more frequent feedback), then yes, you should to SCRUM (the second process you describe) instead of waterfall (the first process you describe has nothing to do with SCRUM).


It seems as you were falling back to old/known procedures. One key concept of SCRUM / agile development is that you don't have a big upfront specification. Of course you need to know about the whole view from the beginning, but you must not put every detail into specification. That is what leads to a waterfall process, which is bad because it is not flexible and changes or new insights are expensive.

When starting with Scrum, you should have an expert Scrum-Master - one who does that quite some time. If you don't have one in your team, you should hire one. At least for the first few sprints.

You also should have the support of your management (as you do), AND the support of your customer, because (s)he needs to provide the product owner. This last point (availability of the customer/product owner) is in my experience very often not the case. Agile still could make sense in those cases, because you can change direction more easily and you could get fast feedback to your work.

BTW: usually you don't specify how the UI should look like. This is an implicit requirement that stems from the feature description. Of course there will be a style-guide that covers all basic UI concepts, but you don't do special UI things for different features, unless this is the aim of the feature.

  • Having an experienced scrum master is ideal, but if someone on their team can't learn it with some training and possibly a consultant, they've got bigger problems.
    – JeffO
    Commented Jun 6, 2013 at 13:57
  • 1
    @JeffO: I mentioned the experienced scrum master mainly because it is hard to break long-trained behavior. When a team is used to do waterfall for several years, it is hard to stop and follow a completely different approach - as you can see in the OP. Therefore it is useful to have someone from outside, who knows the new process very well and can raise a flag when (s)he sees that people (unintentionally) do not stick to the agreed process. It's completely natural that that happens from time to time, even in good teams with excellent developers.
    – Andy
    Commented Jun 7, 2013 at 8:07
  • @Andy having a scrum master would be perfect for us but it does involve additional cost to company. Until we have some kind of success with SCRUM it is hard to convince management to hire a full-time SCRUM master
    – CliffC
    Commented Jun 7, 2013 at 13:47
  • @CliffC: "Until we have some kind of success with SCRUM" ... learning comes at a price. It's just a bit more math than hours * $.
    – Andy
    Commented Jun 10, 2013 at 18:20
  • 1
    @JeffO I used to think that having someone with some training would be enough for a Scrum master, but the problem is that the "steps" in the Scrum framework itself will be the least of your worries. Scrum has the nasty tendency to expose everything rotten and bad in an organisation: centralisation, lack of training, focus on short term gains, individual rewards, silo's, etc. It takes a strong, unrelenting, diplomatic person to confront those problems. It's not an ideal situation to be in as a Scrum master rookie. Commented Jul 12, 2013 at 12:16

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.