How User Stories & Technical Tasks Elevate Software Projects
It’s no secret that most agile teams use technical tasks and user stories to split, track, and show the progress of a project. While user stories are an excellent tool for conveying user functionality needs, they sometimes evolve into something most non-technical people have trouble understanding. Depending on the project and the case, user stories might require additional technical tasks that use more sophisticated tech language and serve as a roadmap or a checklist that helps development teams achieve better results.
Suppose a team worked mainly on setting up a project and its initial back-end. There would be no way of showing any progress if teams didn’t create technical tasks or stories for the completed work. Okay, there is a way, but there should be someone technical from the client’s side who understands the code or can verify what happened in the sprint. The team should inform clients and product owners representing the business of the sprint’s goals beforehand to know what to expect.
Project progress is more than working features and fancy UI/UX design at the end of a sprint. It is a product and team infrastructure development, back-end feature support, refactoring, back-end feature support, bug fixes, and more.
Technical and Functional User Stories and Tasks
Before delving deeper into the vocabulary and the specifics of why we create technical tasks and user stories for our projects, it’s important to note that technical tasks and stories are system-centric while functional ones are user-centric.
- A technical user story focuses on the non-functional support of a system, such as implementing back-end functionality, DB tables supporting a new function, or extending an existing service layer. Sometimes they focus on classic non-functional security, performance, or scalability stories.
- Other types of technical stories focus more on refactoring. And still, another might focus on performing technical analysis, design, prototyping, and architectural work. All of these are focused on underlying support for base functional behavior.
- A third type could be some business logic on the back-end to support the user’s functionality.
Types of User Stories and Technical Tasks
Related to the Product Infrastructure
Imagine you’re building a skyscraper. Would you start from the very top and build down? Or, would you start with the basement and foundation and work your way up? Unless you know something about gravity that others don’t, you’ll start at the foundation.
The same holds with a software project. Start with the foundation (user stories) and build up from there.
Product infrastructure stories or tasks directly support requested functional stories, including:
- New and/or modified infrastructure
- Identifying refactoring opportunities driven by functionality needs
- Initial architecture of the software
- Building the cloud infrastructure that would support the product
- Planning for the DB schema it will be using
These are all parts of the project without which the product cannot start. But how often do we keep track of them? Not enough, in my opinion. Most of the time, the user stories or tasks for this work can be just titles. However long or complicated they might be, they help us keep track of the tasks and ensure we follow the set plan for action.
Related to the Team Infrastructure
Without the proper resources and tools, the chances of building a quality product drop significantly. Team infrastructure-related technical tasks and stories directly support the team and its ability to deliver software.
They often include:
- Tooling — Making sure the team has all the tools they need to do their best work.
- Testing — Many agile teams do not include the testing effort in their estimates or stories, but sometimes testing can take longer than the development phase. It is an underestimated part of a project that sometimes requires dedicated tasks for testing.
- Metrics — Let’s say that the project you’re working on is about fixing performance issues on a website — loading time issues, server response time issues, etc. To optimize something, you would need to know its weak points first.
- Design — The best way to keep track of multiple design changes in a project is to create design tasks. They can be pretty straightforward — only titles named after specific features.
– Registration Flow
– User Profile
– Dashboard
Design tasks can include raw sketches or mockups or even rough descriptions of the project features.
- Onboarding — A good onboarding process brings a ton of value in the later stages of the project and ensures the productivity of new team members. To better track that process, you might consider developing onboarding tasks for the project leads.
While some of these tasks might seem arbitrary and time-consuming, they ultimately bring value to the workflow and help your team keep track of the project’s development.
Back-End Logic to Support a Feature
This category can represent any back-end logic that needs implementation before a fully-functional feature. It’s the skeleton that lives in the closet of every project. The engine of the car. The rocket that brings the rover to Mars. Okay, I’ll stop here, but you understand what I mean.
Teams may create such stories and tasks for:
- Implementing a specific algorithm — We take some input, do complicated operations, and provide a consumable output or result. Take, for example, building a leaderboard for an existing game:
– Generating leaderboards based on business rules
– Distribute the user leaderboards
– Dynamically update leaderboards - Integrating with a 3rd party, another system, or another part of the current system
– Integrate two parts of the same system; for example, integrating a wallet layer with a user layer.
– Integrate with a 3rd party that would support our software; for example, integrating an API for geolocation to display a map with a pin on it. - Making Database Updates
– Updating database structure
– Adding new tables
– Updating tables
– Dropping tables - Implementing Cron Jobs
– A code that runs periodically at fixed times, dates, or intervals. For example, every day at 12 p.m., a file needs to be generated with some records and sent to a government institution. - Implementing specific Listeners
– Executing a code when an event occurs. It can be a simple mouse click, for example. - Implementing Push notifications
– Sending notifications based on events (can be on mobile, desktop, web, wearables, etc.) - Many other possibilities, depending on the project
Tasks for Refactoring
These are stories that identify areas that are candidates for refactoring. Not only does code need refactoring, but it can often include designs, automation, tooling, and any other process documentation.
Spikes
These are research tasks or stories that will result in learning, architecture & design, prototypes, and ultimately a set of stories and execution strategies that will meet the functional goal of the spike. Spikes also need to be on the side of the prototype code documentation, although “demoing” every spike is not required.
Bug Fixing
These are either clusters or packages of bugs that increase repair time or reduce aggregate testing time.
Subtasks
Subtasks are small work sets that can be created under a big functional or non-functional story or task and represent the steps that need to happen before this particular piece of work is ready.
For example, a simple, functional story for searching and auto-populating user data can have the following subtasks:
- Retrieve account information and save it to local storage
- Complete fields to auto-populate functionality
- Create a front-end client for executing the search
- Implement search logic
- Unit Testing
- QA work
– Verify that all fields are auto-populated
– Verify search engine displays suggestions related to the criteria and auto-populate customer information
While such granularity is not needed or used on many occasions, it is a perfect way to split work between different roles in the project or keep track of the active project tasks. Generally, it’s good for the Lead developer to create the subtasks and assign them to the right people.
Should the team demo the technical stories & tasks?
Usually, agile teams don’t want to demo the technical user stories. The rational “excuses” typically fall into the following areas:
- There is no UI, so we can’t demo it;
- They (the stakeholders) only care about the functional software. They don’t care about infrastructure or technical user stories;
- It’s going to be a very odd demo to show this behavior off if we don’t have the supporting functional software completed at the same time;
- It will not be worth the effort to demonstrate non-functional requirements (acceptance criteria).
Final Thoughts
While it’s often harder to demonstrate technical user stories, the payoff is worth the invested effort. Stakeholders may often trivialize and discount them as “fluff” that is low to no cost work surrounding the functionality. Still, the team members know that technical stories are often challenging and time-consuming but integral to quality software development. Demoing the stories and conveying the effort, complexity, and results they bring can truly help stakeholders understand their long-term value.
Original post found here.
Authored by Alexander Alexandrov:
Since joining MentorMate in 2015, Alex has helped the BA team grow from 2 to over 20 members. Software business analysis was a new field for Alex when he started, but he quickly took on various responsibilities in his role. He organizes internal meetings with teams, communicates with clients, trains new BA colleagues, and makes sure that the requirements on different projects are clearly articulated and documented.
Even with his busy working days, Alex always finds the time and energy to read up on scientific topics. He is keen on learning as much as he could about space exploration, the development of smart home technologies, and the future of VR (specifically in the gaming industry). When his dog Molly takes him out for a walk, Alex likes to listen to sci-fi and fantasy audiobooks. Regular workouts and home-cooked food help him keep leading a healthy life.
