When you are expected to commit to a date to deliver a project, how do you do this efficiently? My process is the following:

  • Requirements
  • UI/UX
  • Estimate with dev team - commit
  • Implementation

If the devs do not know what they are building from requirement being an epic, they can't estimate and therefore cannot commit to a timeframe. In addition, if requirements are not properly agreed at the start, I've seen it lead to endless scope creep where the project drags on from Change requests.


4 Answers 4


Agile values responding to change over following a plan

Requirements gathering is hard:

Analysts and clients often speak in different general languages, with analysts often being more technical in nature, while clients will often speak more from a business perspective. This makes common understanding difficult. Tagbo also identified several other general challenges in requirements elicitation, including conflicting requirements, unspoken or assumed requirements, difficulty in meeting with relevant stakeholders, stakeholder resistance to change, and not enough time set for meeting with all stakeholders.

Even if you do it well, there are downsides: Many organizations try to prevent changes by making it very difficult, if not impossible, to inject changes after the initial planning phase. This resistance drives many teams to add everything, including the proverbial kitchen sink, to their initial requirements to avoid the pain of adding changes later.

These are some of the main sources of changes to requirements (scope creep):

  • Allowing change is imperative for companies that must compete in a fast paced, cut throat, rapidly changing marketplace. Project teams that can respond quickly to customers, product users, and the market in general are able to develop relevant, helpful products that people want to use.
  • As the team dives deep into the project and understands the problem space better and starts developing a solution, they get a better understanding of the domain and it becomes clear that some of the requirements are superfluous and new ones are discovered.
  • UI/UX is especially hard to pin down at the requirements stage. Best practice is to try out various options, run it by typical users and make (often drastic) changes based on their feedback.

This is why the Agile Manifesto values responding to change over following a plan.

  • There is nothing wrong with changes as long as it is done at high quality with the time we have remaining. The problem with a lot of companies they do this unrealistically at the expense of quality.
    – bobo2000
    Feb 3, 2018 at 15:08


Project chartering should include enough "planning in the large" to roughly estimate a project, but an agile project doesn't generally contain a detailed project plan up front. Unless your project is very simple or extremely short, such planning won't benefit from the iterative process and emergent design that agility is meant to deliver.

If your project is so simple or short that you don't need iterative development or emergent design, you may not need a full-scale agile implementation at all. This is always a point worth considering.

Agile projects leverage release planning and iteration planning to handle vertical slices of planning. The goal is not "efficiency" per se, although an agile framework can (pragmatically speaking) be more efficient than other methodologies. Instead, the goal is sustainable pacing and continuous feedback. Also, as I have said elsewhere:

The goal of #Scrum (and other #agile methods) isn't to work faster; it's to apply a team's limited capacity more effectively, and to maximize the amount of work not done.

Release Planning

You have two choices for agile release planning:

  1. Set a fixed target date, and continuously modify scope to fit within it.
  2. Define a fixed scope, and forecast (and continually update) a release date based on when the team can complete the scope.

The initial backlog is a set of features and epics gathered from the stakeholders, then ranked by the Product Owner with or without help from others. The Scrum Team must then do just-in-time planning each iteration to deliver a complete increment.

Iteration Planning

Each iteration, the team will develop a small vertical slice that includes:

  • Functional and non-functional requirements.
  • UI/UX criteria.
  • An implementation plan for the current Product Backlog Items.
  • Acceptance criteria.
  • Testing plans.
  • Et cetera.

for just the current iteration. Anything more may change before the next iteration, and violates the agile principle of "maximizing work not done."


One option is to think of the number of functionality modules the application will have and then rough estimate them. Bear in mind, that the next module will incure changes on the already build ones, so that re-work time should be accounted for.

As for the endless scope creep. It is up to the customer to choose between features. You have a limited resource time which means that the work must be prioritised and this should be clearly communicated to the customer/product owner. Basically I ask them, "sure, we could do that, but in order to add this to the scope, what do we take out?"


It depends on the scale of the project, however, one approach you can try in the following areas would be:


Ensure that you've identified and agreed with relevant stakeholders what the mandatory requirements are. If you didn't complete this your project simply wouldn't be functional and/or is unlikely to meet the business case.

This gives you a skeleton that you can start to build upon. This can help influencers feel confident and also give you the scope to prioritise the other features.


It's important that you've thought out (and tested) the potential user flows and actions at each step in the journey of your project. You can then progress detailed UI/UX "just in time" (i.e. before the start of a sprint or a time frame your developers are comfortable with) whilst still making sure the overall experience is on the right track.

It is best if you can embed your UX/UI person(s) into your team. The devs should see the designs early at a wireframe stage to help feedback and understand the technical implications of what is being proposed.

Estimate and commit

Estimations can be tricky. You need to understand at a good level the implication of a story from both a dev and test point of view, alongside this, if your team hasn't been together for long, story points are subjective and therefore it will take you a few sprints to translate them into anything plannable.

I try to look at it at an epic level, running the devs through the proposed journeys at a high level and then get them to guestimate. It could be in sprints or t-shirt sizes (e.g. it's similar to project X, which was a large, so it will probably be Y months).

You'll get a sense from there if your expected timeline is unreasonable or at risk. It's important to manage stakeholder expectations, one easy way of doing this is explaining that you can't provide detailed estimations at this stage, so it's likely to be + / - XX% tolerance.

When you start to do regular refinement and planning sessions, you'll get a better sense of how much time it will take you to get through your project backlog.


Have a demo session at the end of every sprint or at the completion of an epic with your relevant stakeholders. Take them through what the team has accomplished and also share the challenges you've faced. Doing this frequently prevent big surprises later on down the road.

Good luck!

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.