Product Development

Many products is developed for a specific need or is built to either test if some idea is working, or it's simply a "build it and they will come" -approach. The first time the MVP (Minimum Viable Product) is built, one does not have time to think about the scaling or how to work with more complex features and functionality. In all cases, a standardised and transparent agile Product Development process is a good idea to follow, in order to get predictable results.
For maintaining and continuously improve a Product, having a process to handle Requests as well as bug fixes will help getting things done and released.

Our Product Development process starts in the idea stage.

Idea Stage

This stage captures all ideas from anyone in the company. These could be short ideas or big ideas which can be discussed at some idea or brainstorming meeting. As everyone can create these ideas, it’s also a way of keeping the product development open. How things gets transitioned from this stage depends, maybe it’s by upvoting or just qualified by the Product Owner.

Request stage

Normally all requests lands here; bugs, changes, new features. It's the capture lane for everything that employees or leaders wants to have done. A well captured issue contains a screenshot, a short description and a url. The person who is behind requests is called the Reporter, and champions the ticket throughout the process. 

Backlog stage

Only gone thru, well understood and checked tickets can come to this stage, and only moved by the Product Owner, or whoever has the role. Once moved over, they are prioritised from the top and down. Developers will pick from the top to the extent they can, however they choose to work on (another great motivator). No one except of the Product Owner is allowed to re-prioritise or move things in to this stage. It's worth repeating.

In Progress Stage

From this stage, the developers are themselves responsible to move the ticket to Done. This helps with the entire process, as the developer will accommodate and make it go thru as they want to be done. So there is no reassigning happening. Assigned is the lead developer who picked up the ticket. Multiple developers can work on the same ticket, but the assignee is never changed. The developers shares information with the rest of the team every day in the form of a stand-up meeting and answers the three scrum questions: 1) What have I done until today? 2) What will I do until tomorrow and 3) Do I have any issues I need help with.

Blocked Stage

If a developer can’t move forward, the ticket is moved to the Blocked stage. There could be missing content, needing to wait for a Reporter or the solution is not found. Putting something in the Blocked stage in a Kanban project means it's highly visible that something is not moving like it should, and should be take care of.

Testing Stage

Once a ticket is merged to a staging or testing environment, the Reporter gets invited to help testing it. It’s of course pre-tested by the developer before as should be the default behaviour of any developer. Personally I don’t wan’t to move away the responsibility from the developer to a QA-team, which takes longer. But for some larger and more complex testing it could be needed and be faster. Automated testing is also performed.

Done Stage

Once something is merged to the main branch and thus released to production, it is set to done. This is a clear definition of Done.

Wow you just described an old school project! Hold on a bit, what we have here allows for individual ideas/tickets to move thru the process independently from the other ones. That’s the main difference. Also, we can move back and forth any time we want for any valid reason. This can’t be compared to the waterfall project with all its dependencies and testing issues.