Why Agile Release Planning Rocks?
The answer is simple - it takes 15 - 20% of the time a traditional Release Plan would take to be formed by a waterfall company. What that translates to is saving a huge load of money by using the appropriate resources in a common sense sort of way and using their time efficiently. The secret ingredient is simple - it is just about being more agile and scrummy. You have to be cross functional, collaborative, sensitive to time, use relative sizing estimation, do "just enough information and just in time" requirements gathering, always think from a user perspective - which helps avoiding going into an analysis paralysis product design phase.
We are getting ready to form a new Team and so far things are going great! Forming new Scrum Teams with brand new agile requirements, and with brand new locally based team members sounds really exciting to me, always! This situation in my mind is an awesome opportunity to really do Scrum right and reap tons of productivity out of it.
If you go by the recommended Agile way of doing Agile Release Planning, you would start with figuring out what that virtual product is. That would happen through discussions between the Product Owner, Stakeholders, VPs. This discussion should be time boxed and usually lasts only a few hours. The end result of this could be identifying all the users for this virtual product, and the EPIC stories. Once that initial vision of the product is established you can start conceptualizing who (Team Members) you need to create that product and form the team.
The next step would be involve them in the next stage of the release planning in a sort of break out session style. This session would again last a few hours. If there are multiple virtual products you would organize multiple concurrent break out sessions. During the breakout sessions the PO would explain the EPIC stories to the Team members and also talk about rough release plans or deadlines. The Teams would then work together with the PO and SM to break down the stories into smaller User Stories which build small features. These stories would be built on the basis of the Independent-Negotiable-Valuable-Estimable-Small-Testable (INVEST) principle. The SM will play a huge role of making sure this is done in an Agile way. There would be a lot of collaboration between the Team and the PO during this process. We should not be going too much in the "how" to do this phase just yet. Just enough information should be captured and written in (preferably) User Story format. This may be called a pre design phase which is time boxed. Moving away from the traditional way, what could be done is the user stories could be placed in swim lanes which have a high level category - for example "Core Feature 1", "Core Feature 2", "Advertising", "Technical". Each lanes could have their own Epics and the smaller stories could be placed in their respective lanes where they belong. This way you have a clear understanding of where the Story originated from. At first this method might not seem agile, but realistically this method makes it easy for a the PO and the Team to wrap their head around a brand new product, rather than just think of the product as one slice of shippable feature. I say this because most of the infrastructure might not be in place, and there might be some small amount of prep work that might need to be done, hence the "Technical" EPIC lane and so on.
The next stage would involve the PO and the team working out the flow and sequence of all the work to be done. The POs decision will be final on this, although the Team could share their input at all times during this phase, which I think is very useful. Any issues and impediments should be identified at this stage, like need for more resources, or making sure the environments for development and integration are available etc. The release dates will be set during the first stage of this Release Planning. The icing on the cake to this stage would be the Team going ahead and quickly giving each story Story points (eg. Fibonacci). This will help the team break down equal amount of stories for each Sprint and it will also give the PO added advantage of knowing the metrics before even starting the Sprint. Off course, a guess would have to be made on the Teams velocity for the first Sprint.
The last stage would be the Engineering Managers, Architects, POs and SMs getting together and working on resolving any impediments that were identified during this whole day of Release Planning.
Considering the fact that a Release Plan is usually complete within a days time, for a 3 - 6 month project is amazing and very agile. If you add concurrency to this then you get even better results!
If you go by the recommended Agile way of doing Agile Release Planning, you would start with figuring out what that virtual product is. That would happen through discussions between the Product Owner, Stakeholders, VPs. This discussion should be time boxed and usually lasts only a few hours. The end result of this could be identifying all the users for this virtual product, and the EPIC stories. Once that initial vision of the product is established you can start conceptualizing who (Team Members) you need to create that product and form the team.
The next step would be involve them in the next stage of the release planning in a sort of break out session style. This session would again last a few hours. If there are multiple virtual products you would organize multiple concurrent break out sessions. During the breakout sessions the PO would explain the EPIC stories to the Team members and also talk about rough release plans or deadlines. The Teams would then work together with the PO and SM to break down the stories into smaller User Stories which build small features. These stories would be built on the basis of the Independent-Negotiable-Valuable-Estimable-Small-Testable (INVEST) principle. The SM will play a huge role of making sure this is done in an Agile way. There would be a lot of collaboration between the Team and the PO during this process. We should not be going too much in the "how" to do this phase just yet. Just enough information should be captured and written in (preferably) User Story format. This may be called a pre design phase which is time boxed. Moving away from the traditional way, what could be done is the user stories could be placed in swim lanes which have a high level category - for example "Core Feature 1", "Core Feature 2", "Advertising", "Technical". Each lanes could have their own Epics and the smaller stories could be placed in their respective lanes where they belong. This way you have a clear understanding of where the Story originated from. At first this method might not seem agile, but realistically this method makes it easy for a the PO and the Team to wrap their head around a brand new product, rather than just think of the product as one slice of shippable feature. I say this because most of the infrastructure might not be in place, and there might be some small amount of prep work that might need to be done, hence the "Technical" EPIC lane and so on.
The next stage would involve the PO and the team working out the flow and sequence of all the work to be done. The POs decision will be final on this, although the Team could share their input at all times during this phase, which I think is very useful. Any issues and impediments should be identified at this stage, like need for more resources, or making sure the environments for development and integration are available etc. The release dates will be set during the first stage of this Release Planning. The icing on the cake to this stage would be the Team going ahead and quickly giving each story Story points (eg. Fibonacci). This will help the team break down equal amount of stories for each Sprint and it will also give the PO added advantage of knowing the metrics before even starting the Sprint. Off course, a guess would have to be made on the Teams velocity for the first Sprint.
The last stage would be the Engineering Managers, Architects, POs and SMs getting together and working on resolving any impediments that were identified during this whole day of Release Planning.
Considering the fact that a Release Plan is usually complete within a days time, for a 3 - 6 month project is amazing and very agile. If you add concurrency to this then you get even better results!
No comments:
Post a Comment