I’m with yellowjacketcoder, that doesn’t sound very agile-y.
A few questions:
-
When you say “features”, what do you mean? Are they very small bits of work? You want everything broken down into “stories” that are no more than a few day’s worth of work.
-
Once you have things broken down into stories, most shops do sprint planning, where the team asks enough questions that they can estimate each story. The idea here is not to ask every single question, but enough that the team can look at the story and estimate it.
-
Estimating: as I said before, the stories should be small enough & easy enough to understand that the team can look at 'em and estimate with whatever system you want to use. We do Fibonacci numbers (1/3/5/8). Other places do t-shirt sizes (small/mediium/large). Doesn’t matter what you use; the idea is that 1) everyone understands things enough that they CAN put an estimate on it and 2) you can immediately know if something needs more work; ie, it’s a 13 or an XXL, which are not allowed. If the team decides something is that big, someone needs to break it down into multiple smaller stories.
If you’re reworking things every sprint, I’d be willing to bet that you’re not breaking things down into small enough steps, and also that the analysts need to be farther ahead. What’s worked for us is the analysts sketch out “epics” - ie, a few months worth of work - in high detail. We’re not talking knowing everything up front, because we’re agile, and we know as we get into the work that things change. From there, we look at the epic, and roughly break things down into stories.
From there, we look at the stories, and decide what works needs to come first/second/etc. Once again, these are all very rough ideas, with the idea that things can and will change. We then will take whatever tool we are using (Jira, in our case) and put the stories onto the backlog in roughly the order we intend to do them.
At that point, we do sprint planning, and grab the stories that come first. Talk about them, estimate them, etc. Then start working.
At the end of the sprint, we have a retro, talk about what went good/bad/what should change. Then we do sprint planning - grab the next set of stories off the backlog, estimate, start work. Part of sprint planning may be looking at the backlog and saying “boy, we got that wrong, let’s move this set of stories farther down, we need more clarity on this stuff, so let’s talk more about it and write more stories” etc etc.
The whole thing is iterative; at any point, we might stop and say “we need to change this” or “we got this wrong.” We’re also constantly getting better at it, and we realize there is no one true way to do agile. Every team is different, and it takes a while to get into the groove. Keep trying!
