We are going to start with a change. Yep, Agile embrace change and that is what is going to happen in this post. I said that I intend to write about the team but I think it's better to go to the inception deck. But first to the picture from the Agile Samurai:
Inception Deck - From The Agile Samurai written by Jonathan Rasmusson |
Why are we here?
This is all about the reason that the project exists. The are a nice interesting TED talk about it and this website as well that I highly recommend you. We answered this one :)
Elevator Pitch
This is a short sentence that explain the project/product/service you are delivering. If you are planning to start a Startup, that is one of the things you should do. If you want to know more about this topic, specifically how to use it in a Agile project, you can find it in The Agile Samurai. We also did this one. It was very nice and exciting gather the team and write a sentence that defined our project. We even gave a internal name for all project VAMO (Vendas Assistida Móvel Online - online mobile assisted sales translated from Portuguese).
Product Box
I liked this one a lot as well. To answer this question we built a box for the software project we are building. The technique is explained in details in The Agile Samurai. The main objective is to materialize the product although most of the Software don't have a box for it. The box have the product name, a slogan and its main benefits. We built ours and send it to the CIO that got really excited and came to us to ask if the picture we use in the box was the picture from our product. So, first lesson "make sure that the pictures are fake to your stakeholders our you maybe have to explain it later".
NOT List
The question is about scope. What we are going to build, what we are not and what we need to figure out. We did not answer that because it was in the project planning documentation. And we get another lesson from that. One day before the first sprint planning, we have a meeting to explain what we are going to build and what we are not because it wasn't clear in the documentation. So even if there is a formal documentation, try to write this elsewhere in your project to don't get any trouble.
Meet the neighbors
This one got us another lesson and it is related with the NOT List. The neighbors are people that are not directly involved with the project but are interested in the outcomes. They are called stakeholders in some places. And we have a little discussion with one of those neighbors about one functionality that it was desired by the product owner (more about it other posts) but was decided not to be built. To know about the people that are interested in the project is very important, and you should think about it or face the consequences as we did.
I think that is a lot for now. I hope you enjoy this one.
Have a great day,
Gustavo Fonseca
This is a short sentence that explain the project/product/service you are delivering. If you are planning to start a Startup, that is one of the things you should do. If you want to know more about this topic, specifically how to use it in a Agile project, you can find it in The Agile Samurai. We also did this one. It was very nice and exciting gather the team and write a sentence that defined our project. We even gave a internal name for all project VAMO (Vendas Assistida Móvel Online - online mobile assisted sales translated from Portuguese).
Product Box
I liked this one a lot as well. To answer this question we built a box for the software project we are building. The technique is explained in details in The Agile Samurai. The main objective is to materialize the product although most of the Software don't have a box for it. The box have the product name, a slogan and its main benefits. We built ours and send it to the CIO that got really excited and came to us to ask if the picture we use in the box was the picture from our product. So, first lesson "make sure that the pictures are fake to your stakeholders our you maybe have to explain it later".
NOT List
The question is about scope. What we are going to build, what we are not and what we need to figure out. We did not answer that because it was in the project planning documentation. And we get another lesson from that. One day before the first sprint planning, we have a meeting to explain what we are going to build and what we are not because it wasn't clear in the documentation. So even if there is a formal documentation, try to write this elsewhere in your project to don't get any trouble.
Meet the neighbors
This one got us another lesson and it is related with the NOT List. The neighbors are people that are not directly involved with the project but are interested in the outcomes. They are called stakeholders in some places. And we have a little discussion with one of those neighbors about one functionality that it was desired by the product owner (more about it other posts) but was decided not to be built. To know about the people that are interested in the project is very important, and you should think about it or face the consequences as we did.
I think that is a lot for now. I hope you enjoy this one.
Have a great day,
Gustavo Fonseca
No comments:
Post a Comment