Sprint Demos

The sprint demo is one of the most exciting part of Scrum. It’s when the team gets an opportunity to show the fruit of their hard labor during the sprint and all the real value they are delivering to the organization. A demo speaks volumes about your progress compared to status reports, speeches and power-points. So, it's worth planning and investing a little time to do the demo well.

Following are some of the tips to make your sprint demos successful:

Plan time and effort for the demo:  When you are planning the tasks for the user story, plan the tasks of planning and preparing for the demo. Don’t wait to ponder about the demo until you’re done with the story. Plan to write test cases that double as demo scripts. 

Prepare for the demo: Think through an interesting scenario - preferably from an end user perspective -  that you'd want to demo. Plan personas with real name and personalities. Select team member who will role play these personas. Create the necessary test data which look as real as possible. 

Practice: Run through the demo end to end at least a couple of times. Time the demo and record it, if possible, with some screen recording tools like Screencastify or QuickTime etc.

Focus on DoD: While showing the demo, please explain why you think the story is complete in all aspects according to the DoD that you have defined at the start of the sprint. 

Keep it short:  Focus on showing what’s interesting and what’s valuable about each user stories. It should be short and succinct in order to capture the attention and interest of the audience.

Plan the logistics: Study the place and stage (the conference room, lab, a new scrum workplace) properly and make sure you have all necessary tools and gadgets to show your demo. Plan and download all required software in your computer for showing and projecting the demo for your audience.

Plan for failure: A lot of times, the Murphy's laws (this can also be termed as the law of demos) could be in work. Whatever that can fail, may actually fail. So, plan your back-ups including a back-up script. Also the recorded demo could be used as a last resort if all else fail.

Most of the times, the Sprint demos are attended by multiple stakeholders such as the customer and the higher leadership in the organization. This gives the Scrum team ample visibility within the organization. So, make your moves well and carefully!

One note of caution though!

Giving a demo of the working software that the Scrum team just got done is a common practice at most sprint review meetings. But let’s not mistake the goal of the sprint review for a ritual we might perform to achieve the goal.The Sprint team should not go overboard and give undue importance to demo only. The goal of a sprint review is beyond the demo. The Sprint review should focus on how far we are from completing the product as promised and what changes we can bring to adapt to new realities of technical challenges, budget situation and new requirements. So, focusing on DoD and showcasing real product is fundamental. Resist the temptation of showing something nice, but half cooked, un-tested and cannot be released to the customers.

Scrum Culture and Values

Many argue that Scrum and Agile are cultures and values - not processes. They only propose and provide broad guidelines on how a team should think and operate - rather than prescribing a definite process matrix. So Scrum gives a great deal of flexibility on execution - but without compromising the underlying philosophy of agile.





Therefore, it's imperative for all Scrum practitioners  to go to the Agile Manifesto and understand the essence:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

In order for the Scrum to work successfully, the team should show the following values of qualities: 

Be committed, focused and respectful

Be willing to commit to a goal. Scrum provides people all the power and authority to meet their commitments. Focus on doing what you have committed. You are on an important mission. You have every right to say no to any distractions (even when your manager is asking to code for a "quick" hacked demo). Everyone brings their experiences and expertise to the table for the success of the Sprint. Learn to respect multifaceted nature of the team that creates a great product. 

Have courage, openness and flexibility

You have to have the courage to question status quo, question authority. The authority in a traditional set up comes either from hierarchy or from expertise. The scrum team member can question both. Since the progress happens in short sprint cycles, the system permits and self corrects mistakes. You'll not create a catastrophe if you make your own small mistake and learn from it. Scrum urges you to be open, honest and transparent. Commitments are published widely, there is open invitation in any scrum meetings - including the daily stand up. Failing is not a problem, but you need to fail fast, so that you can get up and run again and the whole organization rally behind to help you.

Get yourself in the customer's/End user's shoes

There is a reason behind defining scrum backlogs in the format: "As a user...". You need to get into the consumer's skin to feel the pain or joy that she feels as a result of what you are delivering. This is very different from just responding to some "requirements" created for some faceless entities. This is fundamental. So as a PO, don't shy away from writing product backlogs with extreme superlatives: "As a user, I should get a jaw-dropping user registration experience". When you deliver what you have committed ask yourselves: Am I proud of what I am delivering - irrespective of the recipient/ the customer is going to complain or not.

Teamwork, Teamwork, Teamwork

Though this should have been very obvious by now, but the scrum value topic would not be complete without emphasising it one more time. While the individual brilliance of a rockstar coder is always welcome, responding to change and adapting to new realities become much more tolerable and even fun when you work as a team.

Following agile principles and philosophy is very important, else Agile becomes one more project management methodology in which:

• The project manager or Team leader becomes the ScrumMaster
• Instead of half yearly or quarterly software releases, now there is monthly or biweekly software delivery.
• Instead of weekly status meetings, there are daily status meetings called Daily Scrums.
• MS Project is replaced by or Spread-sheets, Scrumworks or some other fancy tools

When this is the case, it makes management feel more in control, as they can see burn-down charts online, attend stand up meetings to see what each engineer is doing. This in turn makes engineers feel pressured and fearful. So there would a vicious cycle of more control from the management and more resistance and fear psychosis from the engineers. 


On the other hand, to make Scrum a virtuous cycle, map the Scrum processes to the principles from Agile Manifesto:

Sprint planning
The product owner and team collaborate to ensure that user stories are well understood and prioritised for the sprint. The team defines their DoD, commits  (as against signing a negotiated contract or SOW) what it can deliver in the sprint, and customers/stakeholders trust them to be able to deliver.


Daily Scrum
The team updates each other transparently, and the team collaborates and adapts to situations continuously to meet the sprint goals. There is open communication in these meetings and team can always experiment, learn and challenge each other


Sprint review and Demo
Fully Working, shippable software is shown to the product owner and stakeholders during the Sprint review and demo keeping the end user and the customer in the view. Team takes pride in what has been achieved and delivered

Sprint retrospective
The team reflects on how to become more effective and tunes its behavior accordingly. The organization provides support and removes the impediments for the team to perform better.


Process changes are relatively easy, because there is always an audit and compliance that follows the change initiative and you can even get a certificate at the end of it (Like ISO 9000). But the culture change is more difficult, it can be felt and can be seen in long term benefits (including the top line and bottom line of the company), but cannot be certified or proven in a short span of time. So patience, perseverance from  leadership and the team is important.

More reading:  https://blog.scrum.org/culture-change-an-important-ingredient-for-organizational-agility/
https://www.scrumalliance.org/community/articles/2015/january/agile-%E2%80%93-is-it-a-culture-or-process 

Sprint clock for the Organization

To have all of the organization under same clock cycle, we have decided to plan all Sprints to start on a Monday and end on the following Friday (for the 1 week sprint) or the Friday of the next week (for the 2 weeks Sprint). If you do not synchronize our clocks in this way, you could keep losing a day or 2 in between two Sprints.

In order to make this happen, you need to bring some discipline into planning our sprint event planning. Here is a template:

Day 1: Start the sprint

Day 1-Day 10: Daily Stand up meetings

Day 4: Pre-planning meeting for next sprint (for 1 week’s sprint)

Day 6: Pre-planning meeting for next sprint (for 2 week’s sprint)

[ In the pre-planning meetings, check and identify the UI design and Architecture tasks in particular, add them into current sprint if required – so that they do not impede the next sprint]

Day 0 (Day 5 for 1 week sprint OR Day 10 for 2 week’s sprint Friday, preceding the Monday when the next Sprint is starting): Demo and sprint review of the sprint, Sprint Retrospective, Sprint planning for the next sprint

As you can see, the Day 0 (Friday’s) could be very busy. Typically plan for 45 min for Sprint demo and review, 30 mins for Retrospective and 1 hr for next Sprint planning. These meetings should be planned well in advance so that you get time and attention from the senior LT team. Especially, the sprint demo and review should be attended by all as this is the showcase of your hard work during the last 2 weeks and get direct and immediate feedback.

The PO will distribute the user stories/ sprint backlog well in advance, so that the team comes to the Sprint planning meeting with their respective task lists and estimated hours. 

Scrum masters should  plan these meetings in the calendar as soon as possible and book meeting rooms and arrange other logistics as there will be many meetings that will happen on Fridays and during the week.

Sprint Retrospective

Normally, after the Sprint Review meeting, the Scrum Team, PO and the Scrum Master get together for the Sprint Retrospective. In this meeting all team members reflect on the past sprint and check three things: what went well during the sprint, what didn't, and what improvements could be made in the next sprint. The meeting should be time-bound and there should be actionable items (with action owner) coming out of this meeting.

The Sprint Retrospective is an integral part of the “inspect and adapt” culture of Scrum. The team can improve their overall output and team performance only if this meeting is conducted well and in right spirit.  Therefore actionable suggestions to improve performance should be available at the end of the meeting.

A simple moderation technique can be used by the Scrum master to conduct the meeting. Please ensure participation from all in the meeting. Especially the new and younger team members should be given special attention so that their voices are heard. 3 Questions can be asked:

What we should

- Start doing

- Stop doing

- Continue doing

The Sprint Retrospective is not a “root cause analysis” or “postmortem” or “Fact finding” meeting. The spirit of the meeting is lot more constructive and forward thinking – than dwelling in the past and finding who was the culprit! Please keep this essence in mind while you are getting into the Retrospective.

Role of the "Manager" in Scrum

There are always questions raised in some corners about the role of the “Managers” in agile/scrum set up. Let me explain today.

In the traditional team set up, the job of the manager is to identify what needs to be done, to give detailed instructions to the employee, and then to track the employee to ensure that they complete the work according to the instructions. The role of the employee in this model is to follow the directions as given, trusting the judgment and wisdom of the manager. This works well in a factory kind of environment, where the inputs and outputs are well defined and there are not too many variables in between.

But Software development has far more complexity and variability. Requirements tend to change easier and faster, tools and technologies are also changing continuously. In this environment, it is difficult and time-consuming for a manager to understand every detail and issue precise instructions to guide the work of every employee. Within the Team, the work is highly interconnected, with intricate dependencies, and frequent change and surprise. To expect a manager to do all the thinking and planning for her team is unrealistic. As a result, it often constrains the team’s productivity and end up demoralizing them.

Scrum is based on a different approach: The Self-Organizing Team. The team selects and organizes themselves, the team assigns the tasks to themselves, the team commits to the sprint goal and the team delivers and demonstrates what they have committed at the end of the Sprint. So there is a lot more emphasis on thinking and solving problem together in the team and taking decision on a de-centralized manner.

Instead of command and control, a manager in the scrum environment, leads and enables the team to do their best. The manager also is the custodian of the scrum process and should make sure the environment and culture of the team is aligned to agile/scrum culture. This is much more important than the traditional manager’s role and could be both challenging and rewarding. The team needs be aware of this change and actively support the managers to perform and succeed in this role.

Many of the tasks that the managers have been doing would not necessarily change. Here is a typical list of tasks for an agile team manager:

·         Lead the recruitment and hiring of new Team-members (with the active involvement and input of the existing Team-members)

·         Provide support to Teams and their ScrumMasters in helping remove impediments

·         Actively support ScrumMasters’ efforts to protect Teams from disturbance, disruption, or outside interference

·         Provide mentorship and career development advice and guidance to Team-members

·         Plan and manage skills development and training for Team-members

·         Stay abreast of developments in the tools and technologies that Teams are using

·         Provide performance feedback and complete performance evaluations for Team-members

·         Manage attrition and remove non-performing team members

·         Manage team budget – including infrastructure and pay revision

·         Write business proposals for customers/ prospects

·         Stay up to date on industry news

·         Support the team directly and execute some sprint backlogs

To repeat, the managers or the leaders are pillars in an Agile/Scrum organization on which the whole team leans on.

See more at: https://www.scrumalliance.org/community/articles/2009/december/manager-2-0-the-role-of-the-manager-in-scrum#sthash.2Eozn8Q6.dpuf

(Bulk of this material has been taken from here)

Scrum - Definition of Done

Some of the Agile/Scrum principles are deceptively simple and stem from common sense. Definition of Done (DoD) is one of them. Scrum focuses on shippable, usable, fully working software – rather than artifacts that look good on paper, but are hardly used. So, there is a lot less emphasis on creating stuffs like high level design, low level design, project plan, risk management plan, integration plan, Acceptance test plan, review records of all such documents etc. compared to beautifully written, optimized and highly performing code.

So when you say that a user story is done, how do you ensure that it’s actually done or fit for delivering to the customer? “Definition of done” or DoD is what determines if your Sprint commitments are met and what you have generated is fit for a release. This is a kind of release quality checklist, if you like. But the beauty of this checklist is that this is something that is created by the Scrum team for the sprint. This is done by the Scrum team in consultation with the Product Owner as part of the Sprint planning. There is no standard – as this is defined depending on the nature of Sprint backlog and the maturity and composition of the team. This can even change from Sprint to Sprint.

Some of the items that are typically included in DoD are:

1.      Code completed (all parts of the code is done – along with corner cases, test stubs etc., cleaned and commented)

2.      Code checked in to the agreed source control system

3.      Code peer reviewed and met coding standards

4.      Code builds without errors and warnings

5.      Unit tests written and passing

6.      Deployed to Continuous Integration (CI) and test automation environment

7.      Functional test cases are written and test cases passed

8.      All bugs are reported and the Showstopper, critical and major ones are fixed

9.      Integration test cases, performance and non-functional test cases (if applicable) are passed

10.  Code coverage (statement and function coverage) is measured and is within set limit

11.  Code complexity is measured and is within the limit

12.  Remaining hours for all tasks within the user story are set to zero and the task is done.

You can also add design doc updation etc. as part of DoD by all means, if that is adding value to your final software. I just want to emphasize – one more time - on the need of good code!

As always, let me know your views on the DoD. Feel free to share this post with your teams.

Scrum Roles

The Scrum has only 3 recognized roles: The Team, The Scrum Master, The Product Owner (PO). Of course there are other important roles like Manager, Team Lead, Test Lead etc. I’d call them as Leader/ Leadership Team.

The Team:

In Scrum world, all work items are delivered by the scrum team. They are the worker bees – performing all the duties to create the promised product and solution for the customer in smaller increments or sprints.

The responsibilities of the scrum team are:

• Breakdown the user stories to create deliverable chunk called tasks, estimate effort and distribute them among the team.
• Attend the 15 mins Daily stand-up Meeting.
• Ensure that at the end of the Sprint, fully tested (based on Definition of Done - DoD), fully integrated, demoable and potentially shippable functionality is delivered.
• Update the status and the remaining efforts for their tasks to allow creation of a Sprint Burn down Diagram.
• Demo the completed user story, attend Sprint Retrospective meeting and other sprint events.

Scrum is all about teamwork, empowerment, self discipline and taking full responsibility. All team members share the same norms and rules.  The team works in  as autonomous manner as possible. The skills within the Scrum team are balanced and varied: you should have all required skills to complete the commitments in optimal manner. There is no further hierarchy or sub-team within the team (No Java team, PHP team, Testing team). The team is normally co-located and an individual works full time within a Scrum team. Of course this last rule can be relaxed a bit – even though the result will be sub-optimal in doing so.  The ideal size of the Scrum team is 7 +/- 2.

Teams normally demonstrate very well the power of self-organization, if they are allowed to do so and left to themselves.

The Scrum Master:

The job of the Scrum Master to ensure that the Scrum Team adheres to the Scrum process, practices and rules. It’s an additional role of a Team member. She represents the team, remove obstacle and help team members reaching the Sprint goals.

The Scrum master is not a Team lead, Tech lead, Project Manager or a Solid Line Manager. Since it is crucial that there is trust between the Scrum Master and the other team members it would be ideal if the Scrum Team selects the Scrum Master itself and the management does not select her. 

The responsibilities of the Scrum Master are:

• Remove impediments for the Scrum Team (e.g. set up separate meeting, seek external help, escalate issues to the leadership team)
• Guard the Scrum Team from external requests and disruptions
• Ensure efficient communication between the Scrum Team and the Product Owner
• Coach the Scrum Team by asking right questions
• Organize and conduct various scrum events: Stand up meeting, Sprint demo & Retrospection, Sprint planning etc.

The role is very important! It helps you learn leadership by influence and respect without formal authority.

The Product Owner:

The Scrum Product Owner is a central role within the Scrum Framework.  PO represents the end customer and other stakeholders and is responsible for maximizing the effectiveness of the scrum team by driving the resources towards the most important set of tasks. The Product Owner has to work very closely with the Scrum Team and coordinates their activities over the whole lifetime of the project. No one else is allowed to tell the development team to work from a different set of priorities.

The responsibilities of the Product Owner are:

• Creating and managing the Epics / User stories / Product Backlog
• Coordinating with the Product manager or customer or other stakeholders (say a Chief Architect)  to assign relative priority to the product backlog
• Explaining and detailing the user stories to the team
• Attend stand up meeting and help steering the team to achieve the Sprint goals. Attend other Scrum events as well.
• Review and approve the completed user stories by checking them against agreed DoD
• Conduct Sprint planning meeting along with the Scrum master.

The product owner is the customer for the scrum team. So, better listen to her and keep her happy!

I’ll explain the role of the manager or the Leadership team in a separate post – because that will take a but of elaboration.

As always, let me know your views on the roles. Feel free to share this post with your teams.