Return to Answer

The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)

The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)

The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)

The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

    

2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

    

3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)

    

The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

    

2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

    

3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)

    

The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)