[gcanyon]

In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly:

1. I keep a backlog of new features that are needed. 2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided. 3. At any given time, the devs each have 2-3 items they are actively working on. 4. The items range from a day or two up to a week or two for the really big ticket items (e.g. "get performance in boundary cases from 'won't load at all' to 'loads in < 10 seconds'") 5. When a dev puts something in for code review, if they're down to too few items, they check in with me to figure out what to add to their active list. We go over the outstanding list to figure out value vs. effort and make some choices.

Item 5 generally happens weekly, sometimes even every few days. They work fast.

[recursivecaveat]

That is the only way I have worked across 3 employers. I hope I never have to work in arbitrary time-boxed 'sprint' units or something. I never understood the appeal outside of pretty specific circumstances.

[rocqua]

Sprints should give natural points to present to the end-user. Presenting to the end user is essential to getting feedback, and getting feedback is essential to building something the end user will actually use.

You can get feedback without sprints. But they make it easier, and encourage getting something in front of a user fast.

[jbreckmckye]

In fourteen years I've never seen a scrum project that includes user feedback.

At best it led to a stakeholder demo where some business people would look at a form or something, ask some minor questions, then a new cycle would begin (with its context switching, planning stress and perverse JIRA games - all the negatives of Scrum).

I don't think many companies use such regular user feedback in their development process.

Perhaps it's that they don't need to? I actually think a lot of company dysfunction happens when the "official" system purports one set of goals (user feedback, regular pivots) but the "real" system purports others (executive driven initiatives, long sales cycles)

[gcanyon]

Most of the scrum projects I've worked on have been for mass internet users, where feedback came in the form of AB test results. Our current scrum process includes close review with customers, albeit not on a strict two-week/sprint basis.

[gcanyon]

On this project we're presenting to users two to three times a week -- not to the same user, the most frequently that we demo to a single user is about every two weeks, but there are a few we exchange notes with weekly.