An eight-person engineering team kicks off a two-week sprint with a spreadsheet: one tab for the backlog, a manually-drawn burndown chart, and a column for "blocked by," which is really just a note nobody checks until standup, when someone says "oh, that's actually waiting on the auth work" and the room realizes the sprint plan was wrong from day one.
The spreadsheet's real problem isn't the spreadsheet
A spreadsheet can hold a backlog just fine. What it can't do is stay current without someone manually updating it, and it can't tell you that task B can't start until task A finishes unless a human remembers to check the "blocked by" column before assigning work. The sprint plan is only as good as the last time someone updated the row, which in practice is whenever there's spare time, which in practice is never quite often enough.
A sprint is just a list with the right shape
Running a sprint doesn't need a dedicated sprint tool bolted onto the tracker, it needs the tracker's existing pieces used the way an engineering team already thinks about a sprint: a list scoped to the two weeks, story points on each task instead of a separate spreadsheet column, and a goal attached to the list with a numeric target — story points closed, bugs resolved — that updates itself as tasks move to done. "How's the sprint going" gets an actual number behind it instead of a gut-check in standup.
Dependencies that actually get attention
The timeline view is where "blocked by" stops being a note and starts being a drawn line between two tasks. Lay the sprint out against real dates, draw the dependency from the auth work to the task that needs it, and it's visible before the sprint starts, not discovered out loud in the middle of it. When the upstream task slips, the dependency makes that visible immediately, instead of waiting for someone to notice in the next standup.
What "done" looks like without the manual chart
A burndown chart is just a picture of a number that should already be tracked somewhere. When story points live on the task and the goal rolls them up automatically, the team doesn't need anyone to redraw a chart every morning — the goal's progress already reflects exactly how many points closed yesterday, because it's reading the same data the board is built from, not a copy of it someone has to remember to update.
What changes for the team
The team still runs sprints the same way: two weeks, a backlog, a standup. What changes is that the plan reflects reality without anyone maintaining a second copy of it by hand, the dependency that used to get discovered mid-sprint gets caught before it starts, and "how's the sprint going" stops being a question that needs a meeting to answer.