Scrum Ceremonies – Retrospectives
 

No matter how great your team is, there is always scope to improve and get better. The retrospective is way to accomplish this periodically. The main focus is to look at what is working and what is not? Further what are the action items we have based on our learning.  The core focus of retrospective is continuous improvement which is one of the core philosophy of agile.

The primary agenda of this meeting  where every team member is expected to bring their points are

  1. What worked well?
  2. What did not work well?
  3. Action items to improve the process (Mainly action items are result of what did not work well)

How to do it

  • Set the stage. Invite entire team for a meeting (Scrum Master, Product Owner, Team and Customer if possible)
  • Give 10 minutes to everyone to enter their points towards 3 agenda items stated above. The recommendation is to use a tool (For instance noteapp) and send this to whole team in advance to enter their points. This would save time for team in meeting and moreover give enough time to team members to think and state their points.
  • Start with talking about previous retrospectives action items. Close the items which are accomplished.
  • Talk about what worked well, appreciate people and motivate team to continue utilizing the best practices.
  • Further Discuss what did not work well and come with action items
  • Assign owners for every action item.
  • Close the retrospective while action items to go to action item register.

BEST Practices

  • Typically it should happen after every sprint and should last between 30 to 60 minutes.
  • The whole team should participate.
  • This can be considered as “lesson learned” meeting. The notes can go to organization process assets  (Remember “PAL” or “Process Asset Library”).
  • The owners must be assigned to action items. The next retrospective should start with open items of previous retrospective meetings. I have seen, individual teams have excellent ideas while post retrospective nobody really thinks about it.
  • One of the recommendation is to have retrospective of retrospectives to make it better.
  • Don’t point fingers instead work as team and support each other.
  • Do not forget to appreciate your team members.
What is an Agile Roadmap? What happens before sprint starts?
 

The agile roadmap is often confused with product roadmap or scrum ceremonies. The agile roadmap is indeed much beyond that. If it is not just the scrum activities then the question arises in terms of what is agile roadmap all about?  How important is it to know what happens before sprint planning? For most of us, sprint planning is the beginning of agile project while it is not (Practically it can be considered as mid-stage). A lot happen before ‘sprint’ ceremonies.   The agile roadmap would probably answer the entire process that is being followed to accomplish the project.

At a very abstract level, the agile roadmap has 7 phases listed as below:-

Vision

  • Product Owners in conjunction with senior leadership identifies the product vision.
  • The product vision talks about – What your product is, and what it entails? How it would support your company or organization strategy and who is going to consume it.

There are many more factors being considered here including the market, complexity, feasibility etc.

Product Roadmap

  • This phase defines high level of product requirements which are written at high level (EPICs)
  • The discussion between product owner and other stakeholders enable PO to define
    • High level estimates (Probably ROM -> +/- 100%).
    • Priorities

Release Planning

  • The EPICs are further broken down into individual stories.
  • An agile project will have multiple releases with the highest priority features being picked up in order.
  • During this phase release timing for the specific product is determined.
  • The release plan must have to be created at the beginning of the project.
  • The number of sprints, team staffing and capacity is being looked at as well.

Sprint Planning

  • The sprint team works with PO to groom the requirements based on priority.
  • Technical and product dependencies are discussed.
  • Individual tasks are created for each requirement. The next level of estimates are created (+/- 20%). Planning poker, relative estimate, and WBD are quite commonly used to provide an estimation. Based on the maturity or project and organization in the specific area, complexity based estimation can be utilized as well.
  • The team gives commitment by looking at the capacity and next level of estimates.

Please click here to get more details

Daily Standups

  • It should get completed in less than 10 minutes.
  • This meeting should answer
    • What did you do yesterday?
    • What are you going to do today?
    • Any impediment? If yes, then what is that?
  • Please note that standup meetings are not planning or technical discussion meetings. These are neither meant for micromanagement nor a meeting to provide a status.

Please click here to get more details

Sprint Demo

  • This is essentially the demonstration of the working product (or “showcase”). This should happen post QA or peer testing.

Please click here to get more details

Retrospective

  • This happens at the end of the sprint. All the stakeholders sit together and discuss
    • Things which worked well
    • Areas for Improvement or things which we should stop doing it
    • Action Items
  • This meeting should also look at the action items of the previous retrospective and see where we stand. If the previous action items are not addressed, those should be included in current retrospective.

Many times the first three phases are ignored by agile teams.  The ultimate success requires or expects that the entire agile team to be well versed with first 3 phases as well. They should be part of it from day one.

Please click here to get more details