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.
Top comments (7)
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 ❤️
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 :)
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.
Can't wait to hear from you and see what you have done
I think you got the basic process right
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
Tools to use:
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
Time spent on this one: 30-35% of the estimated project time. This includes refinement of the above documents, user feedback and manual testing.
You'll know you did a good job in step 1 if your
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.
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:
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.
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
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!
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 :-)
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.