When you are expected to commit to a date to deliver a project, how do you do this efficiently? My process is the following:
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.
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):
This is why the Agile Manifesto values responding to change over following a plan.
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.
You have two choices for agile release planning:
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.
Each iteration, the team will develop a small vertical slice that includes:
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:
Requirements
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.
UI/UX
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.
Implementation
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!
