Over the years of creating software products for our clients, we became aware of how important is mutual understanding. Without reaching a consensus on priorities and tangible results, cooperation can become a bumpy road. In this article, we reveal a bit of our not-that-secret approach to defining tasks for the development team’s members.
When it comes to software development and breaking our projects down into digestible bits, we incline towards Simon Sinek’s approach and start with a why.
Why
In the process of building a project structure, we focus not only on what functionality a certain feature will serve. We start with recognizing what its context is, where the idea for it comes from, what the dependencies around it are, and what its place in the bigger picture will be. This stage defines business reasoning and the needs behind the feature.
A project manager should explore the client’s motivations and understand their source. As a result, the development team may be able to spot dependencies and connections not identified previously. This helps to understand the context of the task and opens space for the team to propose alternative, possibly better solutions the PM and the customer had not previously come across.
What
This section defines the specific requirements that must be met in order for a task to be assessed as covering business requirements. These points are referred to as acceptance criteria. It’s vital that neither the business nor the PM won’t impose technical elements of the implementation within the requirements if it’s not necessary.
How
What are the acceptance criteria, what needs to be delivered to make the feature work, and what are the possible edge cases to identify? With this knowledge, developers have a better understanding of the feature and testers know which scenarios to check out prior to launching.
Who is responsible for the definition of development tasks?
It depends on who you’ll ask. The client most probably would say it’s them, but we know from a reliable source it’s mostly the project managers. To be fair, PMs are no lonely islands, and the vaunted task definition occurs among brainstorming and discussing their legitimacy.
Ideas for the future (or the already existing, yet requiring some revamping) software project need to undergo some rigorous assessment. The evaluation is necessary to divide elements that are crucial and possible to achieve in the foreseeable future from those that won’t carry significant value for the project or would take ages to create while being of tertiary importance to the product.
The discussion is vital to define the scope of work to be undertaken and divided into tasks. What happens often is some unrealistic image of the project caused by… enthusiasm and anticipation of the client. We’re not saying we don’t understand that. After all, who wouldn’t be overwhelmed with joy just a few steps from seeing their idea become a living product? Still, the cheer can cause challenges, as quite often non-technical clients have only a vague idea of what they’d like to include in the project.
That’s the time for the PM and team to support the client with their expertise in creating working IT products. Drawing from previous projects, we can steer the client towards useful features and functionalities to include in their idea. Or aside from the cheer factor, some customers have a strong drive towards other elements they wish to incorporate into the product with absolute certainty. The only problem is that said items may not have any rationale to come in handy in this particular architecture.
Sometimes, the client is a visionary with lots of ideas and wants to build them all at the same time. That’s when the PMs need to play a killjoy’s role and consider, hand in hand with their team, key aspects of the development tasks. In other words, the right time for all the bells and whistles will eventually come, but they don’t have to be created right away. First, make it work, then make it great.
Task analysis
Tasks we create and develop aren’t crafted for the sole purpose of doing so. All software development work is aimed at delivering tangible results. The task analysis process is all about understanding how users perform their actions and how they achieve their goals. It helps determine what functionalities and features are vital to create a living, working product or service that brings value to not only its creator but also the end users. The approach is meant to question all the goals that are set, fueling understanding and grasp of the details’ importance in the project as a whole.
What are the examples of development tasks?
An exemplary, complete software development project can be broken down into the following development tasks:
- Launching the project, defining its scope
- Defining requirements
- Defining business terms
- Estimating time frames
- Defining story points
- Adjusting story points to sprints
- Carrying out work related to delivering particular story points
- Implementing developed items
- Testing
- Launching production
So, does everyone on the team always know what to do?
Yes, obviously!
Except for when they/we don’t, and that’s perfectly fine. As long as it’s not a permanent obstacle. Should any roadblocks occur, the team knows who to refer to to clear the way for further work.
In a perfect world, everyone would be infallible and unmistakable, but unfortunately, we don’t live in one. In reality, errors, glitches, and misunderstandings happen. What truly reflects the strength of a team (and PMs alike) is the ability to admit their mistakes and reflect on possible solutions. Whether it’s an incorrectly estimated task or an improperly prioritized item, recovery plans can be implemented to avoid future obstacles to overcome.
