Software Developers, Have a Feature? Resist This Urge

As custom software developers, we spend a lot of time looking at the details, don’t we? We examine what SDK to use, how to define models, how often to make calls, and where. Sometimes it’s difficult to rise up for air in our metaphorical pool of technical soup. But we need to take a big-picture approach when tasked with defining the requirements of feature work. Let’s see how.

We were tasked with developing an Android application that matches the functionality of its iOS counterpart. We must break down features in a way that allows developers maximum flexibility to handle subtasks efficiently.

Feature Work: Keeping the Big Picture in Mind

Our main objective is to outline everything developers need to accomplish to complete a feature without overly dictating how each feature should be implemented.

For instance, let’s consider adding credit card payment functionality to the application.

Here’s the too-specific breakdown:

  • Add Plaid SDK.
  • Implement backend endpoints for payments.
  • Set up receipt page composable.
  • Establish reusable composable for navigation wrapper.
  • Integrate Snackbar notifications.
  • Add “verified” tag composable to bank account.
  • Design select composable for bank accounts.
  • Incorporate a delete button into select composable.
  • Establish endpoint for composable.

And what’s the issue with this?

While these tasks are clear for developers to pick up, this breakdown may not capture all necessary work and can be challenging to estimate accurately.

Taking a high-level perspective, let’s consider what’s needed to enable users to make payments using their bank accounts within the app. Here’s a typical set of tasks:

  • Add a bank account
  • Delete a bank account
  • Select from existing bank accounts
  • Verify bank account

Writing Acceptance Criteria That Matters

Now, let’s examine the acceptance criteria for adding a bank account:

Acceptance Criteria for Adding a Bank Account

  • User Interface:
    Users should initiate the bank account addition process from a designated section in the app.
    Clear instructions guide users through entering account details like account number, routing number, and account type.
  • Validation and Error Handling:
    Input fields must validate user inputs in real-time, providing clear feedback on errors such as invalid characters or missing information.
    Error messages should be descriptive, helping users correct any issues during input.
  • Security and Authentication: Adding a bank account must require secure authentication to protect sensitive financial information.
    Authentication methods may include password verification, biometric authentication, or other secure protocols as per app security standards.
  • Integration with Backend Systems: Upon submitting valid details, the frontend should seamlessly communicate with backend systems to securely store new account information.
    Backend systems should handle data encryption and storage in compliance with industry standards such as PCI-DSS.
  • Confirmation and Feedback: After successful addition, users should receive clear confirmation of the new bank account with a notification or message.
    The added bank account should promptly appear in the list of available payment methods within the app.
    A prescriptive approach, such as specifying a particular SDK like Plaid, limits flexibility by prematurely defining technical choices. It’s beneficial to first capture user needs broadly and then detail technical implementation as needed.

Why avoid being prescriptive?

Focusing too narrowly on technical details can overlook crucial user preferences and regulatory considerations, leading to inflexible solutions that require extensive rework.

By starting with a higher-level perspective when breaking down feature work, we ensure all user requirements are addressed upfront. This approach allows for more adaptable development and better consideration of edge cases that emerge from a user-centric viewpoint.

From here, we can further break down stories into more technical details as necessary, ensuring comprehensive coverage while maintaining flexibility. Or better yet, let your developers break it down further into subtasks as they see fit.


Join the conversation

Your email address will not be published. Required fields are marked *