To me, how you break things up into stories is key. For example, you could break it up into design, implement database changes, implement back end and implement front end. I would not recommend it though. Because if you did it that way, the earlier stories provide no user value until you have the last story. If you don't do the last story, you've got dead code (which cost you to develop and will cost you to maintain). Similarly, you don't want to do things like add widgets for future use. You might never get back to it.
Alternatively you could approach it so that the first story was to do the most simplest aspect of it. Then the second was to add on another capability (maybe refactoring a bit), etc. In that way, you could stop at any time. Some customer value has been added (maybe minimal). There is no dead, untested (from a user point of view) code.
One of the hardest things when starting on Agile is getting into this mentality of breaking things up into user valued increments. People tend to get mental blocks about it. "It can't be broken up". A brainstorming session with others can often help.
Some things are really hard. For example, what if you wanted to add support for a new platform? In this case, you could start with a very simple subset of the product (where the rest is non-existent or disabled) and build on it.
I generally find that most things can be broken into two week increments. If there is a push for longer, brainstorm a bit on how to break things up. Worst case, you could disable the intermediate forms from the customer. This should be used only if necessary. The exception not the rule.
In some cases, a prototyping spike might be necessary (where you come up with and evaluate some alternatives). The goal in this case is to get more information so that you can leverage that in future iterations.
On what is releasable... This is something that will change as your project evolves in its agile transition. It might start off meaning that the code is done, unit tests exist and QA has tested it. It might grow to mean that automated regression tests have been modified. And that documentation has been done. And that a full regression has been doe. And that marketing materials have been updated. And that production materials (such as a bill of materials) have been updated. Etc. Eventually, as you push the envelope, any iteration really could be shipped (if you wanted to / if it made since for the business to do so).
This can be very powerful. Because you have less and less things that have to be done, you have more flexibility on what you can do. This could be new capabilities. Or it could be deciding that you want to send this iteration's results to a particular customer for some beta testing.
What is a story
Lots of good points in your comments.
To me, how you break things up into stories is key. For example, you could break it up into design, implement database changes, implement back end and implement front end. I would not recommend it though. Because if you did it that way, the earlier stories provide no user value until you have the last story. If you don't do the last story, you've got dead code (which cost you to develop and will cost you to maintain). Similarly, you don't want to do things like add widgets for future use. You might never get back to it.
Alternatively you could approach it so that the first story was to do the most simplest aspect of it. Then the second was to add on another capability (maybe refactoring a bit), etc. In that way, you could stop at any time. Some customer value has been added (maybe minimal). There is no dead, untested (from a user point of view) code.
One of the hardest things when starting on Agile is getting into this mentality of breaking things up into user valued increments. People tend to get mental blocks about it. "It can't be broken up". A brainstorming session with others can often help.
Some things are really hard. For example, what if you wanted to add support for a new platform? In this case, you could start with a very simple subset of the product (where the rest is non-existent or disabled) and build on it.
I generally find that most things can be broken into two week increments. If there is a push for longer, brainstorm a bit on how to break things up. Worst case, you could disable the intermediate forms from the customer. This should be used only if necessary. The exception not the rule.
In some cases, a prototyping spike might be necessary (where you come up with and evaluate some alternatives). The goal in this case is to get more information so that you can leverage that in future iterations.
On what is releasable... This is something that will change as your project evolves in its agile transition. It might start off meaning that the code is done, unit tests exist and QA has tested it. It might grow to mean that automated regression tests have been modified. And that documentation has been done. And that a full regression has been doe. And that marketing materials have been updated. And that production materials (such as a bill of materials) have been updated. Etc. Eventually, as you push the envelope, any iteration really could be shipped (if you wanted to / if it made since for the business to do so).
This can be very powerful. Because you have less and less things that have to be done, you have more flexibility on what you can do. This could be new capabilities. Or it could be deciding that you want to send this iteration's results to a particular customer for some beta testing.