DEV Community

Gaurav Saini
Gaurav Saini

Posted on

How to be better at new feature planning?

Hey everyone,

TL;DR - Our team is struggling with good technical analysis and planning for new features added into the product, so we need some ideas to help refine our process.

Whenever there's a new feature or a big enhancement to be added into the product, many times we struggle with efficient analysis and planning. This in turn messes up the estimations, and we end up scrambling at the end of sprints either shuffling tickets around or stretching our work hours.

What I've suggested as a good starting point is to have a set of questions written down that cover the basic stuff common to most features or any new work in general. So, for any new feature request coming in from the clients, if we manage to get answers to these questions then at-least we have a good understanding of the LOE that's needed to get the work done, and also ease up the breakdown of big features into smaller tasks.

The clients thoroughly cover the business aspect of the requirements. We need some ideas to get better at the technical side of things. I've felt many times that during planning we are left wondering what should we do during planning, and it all ends up being a wild goose chase. This is the number one problem we want to address.

Also, how much time do you guys usually put into planning a new feature or a module. Eg: if at first glance, something looks like 3-4 days worth of work, than I think it's a good idea to put aside 2-3 hours where we can just brainstorm and think about all the teeny tiny details.

One last question, is it a good idea to have everyone on the team sit down during the planning meeting?

Thanks a lot in advance.

Discussion (7)

Collapse
chandelieraxel profile image
Chandelier Axel

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 ❤️

Collapse
sainig profile image
Gaurav Saini Author

Thanks! this surely does help a lot.
What you said is so true. All of this will indeed take experience and practice, more importantly getting in the right headspace. But help from the community and learning from others' wisdom always makes the path easier :)

What happen if I did X then Y ? Do I end up having Z, or something else ?

This is a very nice point. Right now we are experimenting with questions like this, and trying to come up with a bunch of those which we can ask during planning phase.
Sprint retrospectives are one thing that I'm thinking of taking up first.

Slowly but surely, we're getting there.

Hopefully I'll write a second part to this post, and talk a bit more about what parts we've incorporated into our day-to-day workflow, and probably even list out a set of basic questions so others can also benefit from it.

Collapse
chandelieraxel profile image
Chandelier Axel

Can't wait to hear from you and see what you have done

Collapse
tqbit profile image
tq-bit

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.

Collapse
sainig profile image
Gaurav Saini Author

WOW!! This is really great stuff
I like the fact that you start the actual development so late in the whole timeline and give ample time for the, like you said, the least fun but crucial stuff.
Fortunately, the clients we work with do a lot of the heavy lifting during this phase. Our team is more focused on technical side only, but reading the part about gathering feedback from dev team

Communicate these documents with the dev team and gather feedback!

This has left me wondering if we could make the whole process more of a to and fro thing instead of one way

I’m so excited to start using this knowledge in our project
Thanks a lot!

Collapse
tqbit profile image
tq-bit

yw. if you can, please let me know how it worked for you. I'm not getting the chance to put all tools out at once very often and will appreciate some field-feedback :-)

Thread Thread
sainig profile image
Gaurav Saini Author

Yeah, I’m hoping to write a second part for this post with parts we’ve implemented in our day to day process.
But you might have to wait some time since we’re all a bit new to this and things might take some time to get fully used to.