I think you got the basic process right

1. Write down the requirement in 'human' words
2. Refine into epics, user stories, eventually tasks
3. Do them

TL:DR:
Decide on PM style (agile for complex, waterfall for trivial)
Understand the problem. Do lots of interviews. Gather and maintain intel
Understand the solution. Use visualisations to get the big picture and start breaking it down
Write the code. It should be your final specification.
&It implements your technical solution for the functional problem of your client.

Below steps are vague. I try and follow them whenever I have access to the necessary resources. When in doubt, I cut back anywhere, except for the buffer time.

0: General project management

Always depends on your project's complexity. Using the following matrix to estimate what's it gonna be always turned out to be a good idea

1. Collect as much intel as you can. It's (often) the least fun part to gather and collect. Unfortunately, also the most crucial one. Interview the heck out of your stakeholders. Take time to put things in order. Ask questions. Try to get the functional side of the story.

Tools to use:

• For business cases with workflows, use BPMN2.0 (e.g. with Camunda, Draw.io, Excalidraw)
• For business cases with a lot of complex, nested sequences (imagine the worst if-else hell you can), use a supporting spreadsheet with a matrix showing all cases.
• A written collection of business units (like users, ERP resources, systems) you must consider. Bonus points if you cover interfaces. Extra bonus points if you're able to embed them into your flowcharts (1). Tools to use: Draw.io/Excalidraw, I saw mermaidjs can do ER- models, but never tried it myself.
• A document that enriches the above resources with details and holds them as references (= Functional Specification). This is ideally x-checked by your client's IT-guys, given there are any.
• If you're doing UIs, map out some wireframes. Use powerpoint to make it interactive if you figure your client is a visual learner.

Communicate these documents early to the guys building the project so they can wrap around the case! If they see a flowchart for the first time in step 2, it's too late

The more you cover and write down here, the better. You probably won't cover all cases initially, but can always extend.

Time spent on this one: 30-35% of the estimated project time. This includes refinement of the above documents, user feedback and manual testing.

1. Technical planning

You'll know you did a good job in step 1 if your

• Workflow diagram(s) translate into your code's control flow
• Business units translate into your project's data structure
• Functional specification translates into a technical document supporting these two

What's left to do is how your software fits into the big picture. A good method I've applied once before is the C4 - Model. Like the above documents, once you've built its foundation, you can extend and refine it with little worries.

I've read a concept here called the Critial Path, which also seems like a good idea at this point.

Once you've done got a clear view about structure, flow and data, you can start planning out class diagrams. If you're using a new technology, you can start prototyping.

Communicate these documents with the dev team and gather feedback!

Time spent on this one: 15-20% of the estimated project time.

1. Start the development workflow

If, at this point, you haven't written a single like of code, that's good. You took the time to understand - and possibly already solved - the problem. Now write that code. This includes:

• Actual development of modules, classes and features
• Writing (at least unit-) tests
• Write & refine technical documentation based on the documents in step 2

Time spent on this one: 25-30% of the estimated project time

Now you'll have 15-30% of time left. Depending on the size of your project, you'll want to spend another 10% on roll-out and implementation.

The rest is your buffer. Use it for unexpected trouble, problems during go-live, unplanned client meetings, (un)expected leave of colleagues, and so forth. These events show up as amen does in church and cost a lot of miles towards the deadline.

Hi !

I think you got the idea, now you got to play around with it to become more familiar and drag your team with you on this road.

The context on who you're working with doesn't really matter, what need to be understood (but I think you already did) and now accepted is that writing the code is the "easy" part, the hard part of our job is to understand what the client actually want.

Once you have a good grasp around the need, now it's time to do the analysis and planning part (my favorite). Here, we can't really help you, it's all about your experience : you'll fall into dead ends, activate some traps here and there, but hopefully you'll get out of it with a feature. The more and more you'll do it, the more traps you'll avoid. This part is the most important, this is where you'll uncover problems you didn't even think about : What happen if I did X then Y ? Do I end up having Z, or something else ? Does it fit nicely with the already existing code, or do we need a rework in order to keep this maintainable long terms ?

Then, the easiest part : code.

how much time do you guys usually put into planning a new feature ?

It depend on the feature, for complex one I would go for a solid 40% planning, (this includes the comprehension of the feature/problem, planning the workflow and put some times into writing down tests workflows), and 60% coding.

The more you plan, the less obstacles you'll meet during your coding process, as you already eliminated them through the planning process.

---

Now considering your team workflow :

• The planning should be done by the dev(s) responsible for the task, then shared for advices when needed. Do not block your entire team into a meeting where they'll have to agree on a design or an architecture they won't work on (for now at least). This is usually a job on his own.

• To avoid falling into the same traps over and over, do a retrospective at the end of your sprint : what went nicely, and what went poorly. Honesty without blaming will allow your team to go forward and get better over time. -> If you fail, you fail as a team, no "Dammit X, if you went faster we would have been in times !" should be allowed.

Don't fool yourself either, all of this take times - or should I say experiences, and only practice will buy you experiences.

Hope it help, even a bit ❤️