5 Scrum Values : Commitment, Focus, Openness, Respect and Courage (CFORC,C4C)

Commitment

• Commitment => Dedication => Hard work => Passionate => Happy and Successful.
• Scrum team is made up of self-organizing Development Team members, Scrum Master and Product Owner. All collaborates but no one  controls. In this scenario, self COMMITMENT plays crucial role.
• Commitment is the key element of success for high performing teams.
• Committed teams emit positive energy which reflects on their attitude and productivity.

Focus

• Being Focused means you are working towards the GOAL. Constantly generate value to keep Customer happy and satisfied.
• Your mind (Conscious as well as Subconscious) is thinking about HOW to achieve the GOAL.
• It brings out Creativity. Many of "out-of-box" and disruptive idea comes from being Focused.
• Delivering working product each iteration is not easy. Fully Focused Scrum Teams can plan well ahead. They will be able to Inspect and Adapt to the changing situations effortlessly. They will be more AGILE.

Openness

• Openness, Fully Transparent, NO Secretes, NO office politics, NO back stabbing.
• Be Open about your capabilities, constructive 360 degree feedback, keep an Open mind about new ideas, new way of thinking.
• Actual status of the development is visible to all stakeholders. Team members willingly collaborates to generate maximum value.
• Impediments are also made visible, so fast actions can be taken.
• Bottom-up and cross-functional information flow will improve organizational productivity.
• It brings out TRUST between each other and strengthen bonds to work as single unit.

Respect

• Respect can't be WON, it MUST be EARNED. It's a core principle at Servant Leadership management style of Scrum Framework.
• Scrum teams are formed with cross-functional members having multiple competences.
• They all SHOULD Respect each others expertise and point-of-view to work as a cohesive unit.
• Management and Stakeholders SHOULD Respect Product Owner (PO) for his decisions for maximizing Product profitability and Development Teams productivity.
• Scrum Master SHOULD be trusted and respected for implementing Scrum rules and guidelines at every level of the organization for maximum benefits.
• Development teams SHOULD  be respected for their ability to produce working Product at end of each iteration.

Courage

• “Success is not final, failure is not fatal: it is the courage to continue that counts.” - Winston S. Churchill
• Give your best, Inspect the results, Adapt to improve....and do it again!
• Have the Courage to share your knowledge, to ask for help without hesitance, to try new ideas without fear of being criticized and to oppose when you don't agree.
• Constructive criticism is healthy for the progress. It brings out best and brightest ideas.
• Have the Courage to say NO to Product Owner, when s/he tries to give more User Stories for the Sprint.
• Have the Courage to say NO to people, who asks you to do additional work out of Sprint.
• Have the Courage to delay the Release, if Quality of the Product is not meeting the Acceptance Criteria or Definition of Done.
• Have the Courage to respect Time-box boundaries, which will improve team morale.

Estimate a User Story

You can't build a great building on a weak foundation. You must have a solid foundation if you're going to have a strong superstructure. - Gordon B. Hinckley

Estimating User Stories is an important FOUNDATION activity in Scrum projects. With experience and practice teams will get better at estimation, which will help to plan and forecast production Release Schedules and project completion dates.

Let's discuss few popular methods out of many available.

1. Planning Poker (Most Popular Method using Fibonacci series)

• Estimating effort required for a user story relative to each other.
• The TRUE democratic process, time boxed. Scrum Master may get involved to break the impasse.
• A Scrum team member will read user story out loud, which will initiate the discussion for clarification and better understanding.
• At end of discussion, each development team members will pick and raise a numbered card depending upon effort involved as per his/her understanding and analysis.
• Member with the highest and the lowest number will give their reasons for the estimation.
• Team members will discuss further and ask questions until all are in the agreement.

2. Estimating by 'Ideal Time'

• Estimating the size of User Story with work hours required to complete. Assuming those work hours are focused and without interruptions.
• These usually works for the projects where teams are seasoned and established. They have a fairly good idea about the work needs to be done and how long it usually takes. Repetitive activities with few variances.
• Team's Velocity per Sprint has been established. So, project forecasts and Release Planning are more accurate.

3. Using T-shirt size terminology

• Sizing User Stories with day-to-day T-shirt size terminology like S, M, L, XL etc.
• This method is used when teams are new to the concept of the Scrum and are involved in less technical projects. So, members can easily relate and adapt easily.
• It still serves the purpose of Agile methodologies and Scrum Framework which is to provide estimation for Sprint planning.

Why should we estimate a User Story?

• So, Scrum team will actually start thinking about the work involved. The subconscious mind will start working on it while the conscious mind is busy doing current work on hand. Multi-tasking without any loss of productivity!
• Your Scrum planning meeting will be quick and effective. You will have more time for asking questions to understand the requirements and deciding on "Acceptance Criteria", test cases etc.
• To calculate team's Velocity per sprint, so that we can forecast project completion, budget etc.
• It will help us to forecast, plan and prepare for production Release planning.

Who estimates a User Story?

• Development team - They will always have the final say because they do the actual work.
• Experienced Product Owner, who is aware of Team's capacity/capability can usually provide initial estimate while writing User stories and ordering Product Backlog items.

When should we estimate a User Story?

• It's a continuous process till the User Story is completed and accepted.
• At the time of creating/writing a User Story.
• During Product Backlog Grooming sessions.
• During Sprint planning session.

When should we calculate a User Story points?

• During Sprint planning session. This will help us to select Sprint Backlog item based on team's Velocity.
• Before Sprint Review meeting, so that we can compare our estimated value with completed actual value. Delays can be explained to the stakeholders.
• At end of Sprint Review meeting, to calculate accepted stories vs delivered stories. The difference will give us information about incomplete work.
• The reasons for deviation can be discussed during Sprint Retrospect meeting to discuss what was missed and how to improve?