harisrid Tech News

There’s a lot of work involved in pre-planning – a wise manager.

An Intro

Alright, let’s talk about something that we don’t really teach you in undergrad days, but it’s an industry expectation – feature planning. For some folks, it’s a harder skill to learn, and for others, it’s easier. And it’s not just feature planning – it’s all the other surrounding skills – estimating points, figuring out dependencies, and breaking down ambiguous, ill-defined work into smaller, concrete, more manageable chunks.

So how do we do this? In fact, I’m still getting better at this skill, because feature complexity increases in complexity with level complexity – the complexity of senior-staff engineer’s features typically eclipses that of a mid-level engineer’s.

But what makes feature planning so difficult?

• Ambiguity – features get harder to develop.
• You need to meet people – no one takes features all by themselves. You need to set up meetings and communicate to multiple organization personas
• Timelines – multi-quarter features are harder to break down ( versus two-week deliverables ).

Tell me the skills I need!

• Task Decomposition – breaks down a large task into smaller tasks. Breaking down makes estimating timelines easier – a three day task is easier to estimate than a three-week task.
• Task initiation – can start on a task.
• Points estimation – estimates complexity with mostly accurate precision.
• Establishing Priorities – can context switch and work on other features if they’re more pressing
• Work Delegation – can create multiple stories and tasks and delegate them off to more junior engineers; place trust that other engineers can execute with autonomy.

Can you share an example User Story with a Tasks Breakdown?

Rock star senior engineer Archit works on a feature and needs to set up an ETL pipeline from an OLTP Database ( e.g. DDB ) to an OLAP Database ( RocksetDB ) for an up-and-coming reporting & analytics requirement. It’s a multi-week long effort ( at least one-quarter ), and Archit is on the design stage.

Archit needs to write up a story about being on the design stage, but is struggling because “design” , in itself, is an ambiguous term. User story title “Design an ETL Pipeline from DDB to RocksetDB.”. Ok, well, it’s concise, but not granular enough.

What are some tasks that we can introduce in the design stage?

• [1] Gather business requirements – functional and non-functional
• [2] Identify access requirements, caveats, dependencies, and major blockers.
• [3] Brainstorm, get initial ideas and proposals, and identify best candidates
• [4] Identify technologies and mechanisms to make design changes happen
• [5] Write up a first-draft version of the FRD ¹
• [6] Write up final-draft version of the FRD

The tasks don’t have to be followed in a rigid, linear order, but the ordering specified above breaks down the steps.

Each task helps sets the agenda for meetings. E.g. for task #1, a 30 minute – 60 minute XFN ( cross-functional ) meeting can be coordinated with engineers across teams. Task #2 instructs the need for future meeting with stakeholders or L&M ²to adjust deadlines according to identified blockers. The tasks also introduce structure & scaffolding – if the design stage extends longer, we can create phase-based stories and migrate the tasks around – phase#1 can group tasks (1-3) and phase #2 can group tasks (4-6).

Give me a second example of a user story!

Alright, so Archit wraps up the (1) design stage and (2) the development stage of his works. His next tasks are to work on (3) the testing stage and (4) the deployment stage. Both make for solid standalone stories. How can we set them up?

His user story title – [Testing] Write up tests for the latest feature – is short and concise : good for both technical audiences and non-technical audiences.

But what are the tasks? Can we track tasks to view completion? What are good tasks to introduce in the testing stage?

• [1] Write unit tests for the feature and get unit tests to pass in local env
• [2] Trigger a feature build – have unit tests pass in CI/CD pipelines.
• [3] Write integration tests that pass in non-PROD env.
• [4] Write integration tests that pass in PROD env.
• [5] Write end-to-end tests that pass in non-PROD env.
• [6] Write end-to-end tests that pass in PROD env.

The benefits of this breakdown are :

• Dependency identification – we can create an abstract “DAG” ( Direct Acyclic Graph ) in our head and identify dependency sequence across tasks. In this case, we can see that task [1] has to be done before task [2] and task [2] has to be done before tasks [3-5].
• Task Isolation – granularity helps us isolating and break down tasks. Ok, can we break down a deliverable by different conditions – by environment, by testing type, and by involvement of build-pipelines?
• Facilitate trackability – a testing story can take a sprint ( or two ), and tasks can take their corresponding number of days. This helps your product owners and leadership & management get a better view of what’s going on.

Wait but what if I don’t actually need to write integration or end-to-end tests? Well, that’s fine. We can remove them. The boilerplate structure above helps us understand an initial scope ( to do effective estimation ), but we can simplify further.

Street-Fighting Tips

I learned these tips from others, such as direct managers or PMS, so credit is due to them as well! They are not all originals.

• Phase-based development – if a feature takes multiple sprints or quarters, can we introduce phases ( e.g. phase #1, phase #2, phase #3 )?
• Scope down – it’s tempting to do everything “under the sun”, but that’s unrealistic. In a given Sprint ( or other timeline ), expect to primarily focus on 1-2 major deliverables ( or goals ) at a time.
• SDLC Tagging – make it clear. Are we in design, development, testing, or deployment? If we’re given a feature we make user stories, can we add tags to the stories ? It’ll help others not only track your work, but categorize your stories in the future ( e.g. list all design stories or development stories ).
• Track dependencies – does F3 have a dependency on F1 or on F2? This instructs on deadline changes.

Terms and Definitions

1. FRD – Functional Requirements Document. Where developers establish the scope and gather functional requirements and non-functional requirements from a top-down level view. ↩︎
2. L&M – Leadership & Management. ↩︎