User stories and a lot of negotiation over what's essential and what's fluff.
A lot of negotiation.
Also a lot of back-and-forth on architecture. Scrum requires a stable, proven architecture. However, there are always upgrades and enhancements. How do those fit with the backlog? That's a lot of political jockeying between product owner, technology folks and (to an extent) users/buyers.
The process in inherently non-linear.
It's more like crystallization. You have a solution, you start to write stories, you have a technology vision, you have a team with certain skills and experience.
Any one of these features can serve as a "nucleus" for deciding what goes into the backlog and in what order. Eventually, something becomes the nucleus and the mixture crystallizes. Sometimes the cost or schedule or risks are unacceptable, so you heat it back up, find another nucleus and see if it crystallizes acceptably around that new nucleus.
The recrystallization happens after each sprint, by the way, making it even less linear.
Edit. "stable proven architecture".
Question: Who pays for learning the new architecture?
Answer: Ha ha. There's no good answer. So be careful how much architectural learning you do while you have development sprints going on.
If you don't have an architecture in place that (a) works, and (b) can be articulated by almost everyone on the team, you're going to spend time assembling that architecture.
What does the time and cost of creating an architecture do to your first sprint?
You have to incorporate architecture development into the first sprint, delaying things.
Let's say you decide to implement a LAMP stack. You don't know whether to unix PHP, Perl or Python. So you pick one. Like Python. And you promise the first sprint in four weeks. So you work for 3 weeks struggling with the kabillion add-one modules and frameworks. After 3 weeks, you think you have a working tech stack, but you don't have the promised sprint.
Do you delay? If so, everyone asks if you've got the pace right and starts doubling the time for all other sprints.
Do you deliver nothing? If so, what's the point of sprints if you have nothing at the end except infrastructure?
You can change, modify and enhance the infrastructure -- in manageable pieces. But to build a fresh architecture, prove out the pieces, train everyone and develop best practices takes time. A lot of it. And that time shouldn't -- really -- be charged as sprint time creating deliverable product. That's overhead time.
Edit. Tooling.
Rule 1. Agile processes don't use a lot of complex tools and processes. That's why I said that the process is a lot of "negotiation". Whatever makes you productive.
Rule 2. Don't over think it. Just do it.
Most folks say -- in the strongest possible way -- use 5"x8" paper cards and stick them to a wall. Seriously. No tools. Just simple paper, markers, tape and blank wall space.
Read this: http://www.agilemodeling.com/artifacts/userStory.htm
You can use a spreadsheet to collect user stories (and epics -- stories that have to be decomposed). You can add columns for complexity (story points), cost, priority and release, and use it for project management.
We use use cases (not user stories) but the tooling is the same. A use case is -- in a way -- a user story with more details up front. But the use case name can summarize how an actor interacts with a system; the interaction can usually be summarized with clear, simple nouns and a verb, which is very much like a user story.
Spreadsheets seem handy because you can rearrange the rows at the end of each sprint. You can do simple counts and sums to work out how much each feature will cost and when they'll arrive.
I don't use a spreadsheet because -- in spite of the GUI glitziness -- I find it a little bit cumbersome. I would feel it necessary to write a spreadsheet extractor that would turn the backlog from an Open Office Org file into ReStructuredText (RST). I prefer RST -- plain text markup -- over spreadsheets.
This is all protracted negotiation. Everything changes as a result of every conversation. That's the point of an Agile method. Quick sprint followed by negotiation over the direction of the next sprint.
Our backlog is a big RST document. We publish all our documentation using Sphinx and it's very, very simple to write backlog, use cases, architecture, design, etc., in RST markup.
Our sprints are simply sections of a big document tree. They're decorated with a few special-purpose interpreted text fields for the subjective things like estimated completion date, and status (in process, released).
