Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Lindsay DAndrea
3,166 PointsHow to handle devops tasks which may take more than 1/2 day but are not framed by user value?
Often especially at the start of a software product there are a lot of tasks for the team to refine that have to do with set up, access, or foundational process/deliverables. How are these tasks—which may take more than half a day but are not framed in direct user value—defined? And who can most appropriately define them?
1 Answer
Kari Brooks
Treehouse StaffThese tasks are typically called technical tasks or spikes and they're handled differently from user stories because they don't map to direct user value.
Technical task / chore is straightforward setup or configuration work (e.g., "Configure CI/CD pipeline," "Set up staging environment"). No user story format needed — a clear title and description is enough.
Spike is time-boxed research or investigation tasks where the output is knowledge or a decision, not working software (e.g., "Evaluate authentication providers"). Spikes are explicitly time-boxed, meaning the team agrees upfront to spend X hours and stop.
Rather than "As a user...", these are written as straightforward task descriptions with a clear definition of "done." Example: "Set up AWS staging environment so that the team can deploy and test feature branches independently."
(The "so that" part is needed because it frames value for the team or the product.)
Who defines them? This is where it differs from user stories. Technical tasks are best defined by the engineering team — who will identify and size them, since they understand the technical dependencies. A product owner or dev manager should still be aware and sign off on time allocation, since these tasks compete with feature work for sprint capacity
A practical approach is to create a technical backlog alongside the product backlog, and treat foundational work as its own swim lane or epic. This makes the work visible without mixing it into the feature backlog and gives stakeholders a clear picture of why velocity on user-facing features is lower early on.