Daily Scrum Mistakes.

After researching techniques that would improve my Daily Scrum.  I thought I would highlight some mistakes that can occur within a Daily Scrum Meeting that you can further improve to make your Daily Scrum more appealing.

I read an article on “Scrum from the Trenches” Daily Scrum Mistakes  that echo’s some of the sentiments felt by myself.

The first mistake that people often make are to over run the allocated 15 minutes.  This can cause people to lose focus on what the Daily Scrum meeting is truly about.

The second mistake that people make, and I myself allow this to happen on occasion, is that Team members are effectively Reporting Status to the Scrum master.  Many people look at the Scrum Master whilst giving their status rather than giving a status report to the whole team.  I try to not make eye contact with the person speaking as to avoid it being a status update aimed at myself, rather than to the whole team.  The Scrum Master is part of the team and holds no managerial authority, so therefore a status update should be aimed at the whole team and not just the Scrum master in general. 

Leading back to my first point about the allocated 15 minutes. Remember the Daily Scrum is a status meeting.  It is very easy for a Daily Scrum to become a design meeting when one person is describing difficulties that they are having.  The Scrum Master has to be aware of this and limit technical and design discussions.  encourage Team Members to take their discussions “offline” and discuss the possible solutions after the Daily Scrum. 

The best possible way to conduct the Daily Scrum is to have the attendees standing up.  If the Team are sitting down, they become more formalized and meetings tend to run over.  If the Team are standing the meeting becomes more efficient due to people wanting to have the meeting done and dusted quickly so that they can sit down again! 

One problem that I had in the past with my team was that we were always being drawn into design and technical meetings in our Daily Scrum.  The Scrum Master must be firm on this.  I see myself as a nice guy, but at the beginning I was too nice for my own good.  I was worried that continually interrupting these meetings, would see me as being labeled rude.  But I soon realised that the team were labeling the meetings as laborious as they continually over ran.  So therefore I had to step in and limit the design and technical discussions until after the meeting.

we now have a designated time where we allow converse with interested parties after the Scrum meeting where Team Members can gain clarification on requirements of discuss problems with other team members.  I would say that this has improved our efficiency overall as the Daily Scrum is useful again and not laborious.

Scrum Alliance

The Scrum Alliance site is a very good resource for Scrum Articles, Scrum Training and finding out where Scrum gatherings are happening around the world.

If you have not checked it out yet, have a look.  It may be of use to you.

Scrum Alliance Website

How to fit QA into Scrum

 I read an interesting article that addresses some of the problems that my own team has encountered with trying to fit QA into Scrum.  We have found that on some occasions coding new functionality for our site can take up a large part of the sprint, which can have a knock on effect on the time that QA has in the sprint.

We know that this isnt exacly the scrum way of doing things as we should be testing early in the iteration and leaving the testing till late on in the iteration can seem like a waterfall practice, but sometimes needs must.

The article below explains a process that my Scrum team has carried out.  We basically move our QA’ing of the stories into a separate story and have this prioritized in the next iteration thus allowing us to complete the QA without falling behind.

How to fit QA into Scrum

This also leads onto a future article on Automated testing in Scrum :)

How Scrum has improved our QA

I have worked at a web based startup company for the past 3 years.  Before we implemented Scrum just  under two years ago now, the QA team, of which I was a part of was a separate unit from all other teams.  We worked with the watrerfall method of development which meant we were involved in testing our functionality late on in the project.

One problem with this was that if the project was over running, then our QA time was cut and we had to work hard to make up the time lost in development by staying late on occasion.  This seems to be a common scenario with testing in the waterfall method.  Another scenario that I found was that the team became stuck in a rut with testing.  We became stuck in a routing of testing products in linear fashion that it felt as though every cycle was like groundhog day.

When we adopted Agile Development we had 4 main areas of expertise that were split into 4 main teams.  The ratio was around 1-5 (QA-Dev / Flash) and QA is part of the Scrum development team.  The Business side is driven by the Product team and our sprints are 2 weeks long.  This was the start of something new for our QA department.  Rather than being stuck at the end of the process, we were now included from the planning stage with Scrum.

We could now see the criteria being set down by the customer in the user stories that were provided to us by the Product Owner and any prototypes that were supplied. We now had an insight as to how the product should look and feel before the planning stage.

At first the planning stage was alien to us.  We had not been involved in any planning before with the waterfall method.  We had usually been given a product spec to write our test cases against before we were given the product to Test.   Being part of the planning stage felt as though we were now part of the team, rather than something stuck onto the end of a project to make peoples lives a misery.

Taking part in the planning meetings allowed us to gain a more in depth insight into what the product being developed would be expected to do.  Listening to both development sides to our teams plans on how they were going to code the functionality and how both Flash and .net would link together gave me an insight into any problems that may occur that could cause bugs in the code.   I would then be able to ask how I could go about testing these areas and include this in my test case.  This means that we are able to write our test cases earlier with the help of the User Stories and the developers.

Being part of the team during the development means that we are able to test earlier in the process. We have our own development environment which is updated regularly with new builds of the code base.  Once these new builds have been installed we set about testing them and raising bugs.  By testing against the criteria set down in the user stories and in our test cases earlier in the process, we can then find bugs early and have them fixed earlier thus meaning that we are not rushed off of our feet come the end of the iteration or the end of the project, had we been undertaking the waterfall method.  With this in mind QA can help in the process of “defining DONE” for each Sprint which helps to keep the project on track.

Overall I have found an improvement in our working practives by implimenting Scrum.  We have become part of a team rather than a seperate entity which helps us in our goal to try and have fully functioning software that is free of bugs.  Being involved in testing earlier in the project has helped break the ground hog day effect as with the nature of Sprints, we could be testing more than one product at the same time, so this can break down the boredom factor of working on the same product for a long time.  I have certainly found that our products have been going live with less bugs than before Scrum, so identifying these bugs earlier in the project has helped us.

Allan

The Mythical Product Owner Role

I was forwarded this article by a colleague.  It basically describes the product owner role and categorises the different types of product owner.  As a Product Owner could interpret their role differently depending on their ‘Day Job’ role it means that there can be different types of Product Owner depending on their role.

Take for instance, a product owner who works as a release manager, would be different to a product owner who works as a project manager.

It is an interesting read.

Scrum The Mythical Product Owner Role

What is Scrum?

Scrum is a framework or rules that allows you to tailor your own lightweight process to develop new products. Scrum is simple, it can be understood and implemented in a few days, but it takes a lifetime to master.

“Scrum is not a methodology - its a pathway” Ken Schwaber

Scrum will also help you fail in less than 30 days.  Unlike the waterfall method where the product is fully developed and then sent for testing.  Scrum works in iterations of 30 days (or less if you have chosen short sprints).  Each Scrum Iteration will aim to have potentially shippable code at the end of the iteration.  This can then be tested and demonstrated to the customer.  If the product developed does not work due to technical problems or it is not what the customer wants, then this will be found out within the 30 day iteration and can be subsequently dealt with.  This is the opposite of the waterfall method, where it could be potentially a year down the line until you find out that your product does not work as expected or it is not to the customers needs. 

Also, Scrum can also cater for the ever evolving needs of the customer.  Code built using the waterfall method are often planned over a large timescale depending on the size of the product.  It may be, that by the end of development the customers needs have changed and therefore the product being developed may be obsolete and may need further development to get re-tailor it to the customers needs.  With Scrum, we can track changes and enter these into the backlog.  By evaluating and adapting, we can better tailor the product to the customers needs sooner rather than later.

Effective Story Writing in Scrum.

A major part of the Scrum Process is Story writing.  I decided to research the art of story writing so that I could improve my own story writing and hopefully improve the story writing capability of my team.

I discovered that all User Stories follow the same format.

As a <USER> I want <FUNCTION> so that <BUSINESS VALUE>

So as a Web based company, an example of a user story at my company could be: As a <NEW USER> I want to be able to <REGISTER> so that I can <USE THE WEBSITE>.

I then visited the Mountaingoat Software website for more information on story writing.  I found that they use an acronym to help users write better user stories. I N V E S T.  This stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.

Independent:

The story being written should not carry any dependencies.  This could lead to estimating and prioritization problems.  An independent story can ideally be worked on without the need to pull in any other stories in order to complete it.

Negotiable

Stories should have room for negotiation between the Team and the Product Owner.  They are not a solid contract but some room for requirement change should be available.

Value

The story being written must have some value to the users or customers, not the developers.  Stories should be written with the user or customer in mind.  The story should define what a user can do and what benefit this would bring to them if the story is implemented.  If there is no value to the customer or user, then the story should not be prioritized.

Estimatable

The Team should be able to estimate the amount of work that is needed to complete a story during estimation.  If the team are unable to estimate the story, due to ambiguity, the stories requirements should be made clear.  If the team are unable to estimate due to the size of the story, you will need to break the story down into smaller stories.

Small

Stories should be Small and relatively un-complex.  Large stories by nature seem to be complex to manage and more often than not are 2 or more stories combined.  Large stories should be split up into smaller stories in order to make them more manageable.

Testable

Stories should be in a testable against a predefined test case to verify that the story has been completed effectively.

Hopefully this will

The Ball Game

I attended my Certified Scrum Master training held by Tobias Mayer and Mike Sutton in September 2008. This was a brilliant course that had a practical element built in to help us learn. One of the practical elements was a game called ”The ball game”.

I have taken this from Mike Sutton’s Blog at Agile-Blogs. It is a great game and well worth trying with your team.

Timing: 20 minutes.
Ingredients:

• People and space
• about 30 balls (ping pong balls will do )
• Stop watch
• Flip chart to write down scores.

Directions:

1. Form one big team
2. Nominate a Starter.
3. Nominate a Finisher
4. Take 1 minute to plan how to score as many points during next round of play.
5. Announce how many points the team will score during the next round of play.
6. Play for 2 minutes (following the rules below).
7. Repeat steps 1 to 6 , five times.

Rules:

• Ball must have air time (a throw)
• A player cannot pass to anyone directly beside or in front
• Player can have only ONE ball in possession at a time
• Dropped balls are discarded and returned to the container
• Ball must go round all players and returned to the container to score a point.

Learning Points:

• Demonstrate self organisation and iterative working.
• Illustrate the ‘responding to change’ power of working in a highly collaborative and agile way.
• Demonstrate the power of inspection and adaption and continuous improvement.

Devised By:  Boris Gloger

Taught to me by: Tobias Mayer + Mike Sutton

The Ball Game as played at the 2008 Fall Scrum Gathering in Stockholm.

Scrum Development Wiki

A Link to the Scrum Wiki page that describes the basics of Scrum. Also has some links to video’s which may be of interest. 

 Scrum Wiki Page”

Scrum definitions explained

Scrum has a lot of terms used to describe specific parts or roles that are used from day to day.  This sometimes confused people and daunts them when they hear a term that they don’t understand.  Some are easy to relate to, but some are pretty obscure.  So if you don’t know your Pigs from your Chickens… Read on :)

Average Velocity

     The number of points completed in each of the Team’s Sprints divided by the number of Sprints completed.

Burndown Graph.

     The trend of work remaining across time in a sprint, a release, or a product.  The source of the raw data is the Sprint backlog and the Product Backlog, with work remaining tackled on the vertical axis and the time periods (days of a sprint or sprints) tracked on the horizontal axis.

Chicken

     Someone who is interested in the product but does not have formal Scrum responsibilities and accountabilitys (is not a Team Member, Product Owner, Scrum Master or other stakeholders).  Chickens can attend Scrum Meetings, but they must not speak as they are not part of the team.

Daily Scrum Meeting

     A short status meeting held daily by each team during which the team members synchronize their work and progress and report any impediments to the Scrum Master for removal.  Dependencies on other scrum teams can also be reported here in order for the Scrum Master to try and deal with before they become an impediment.

Estimated work remaining

      The number of hours that a Team member estimates remain to be worked on any task.  This estimate is updated at the end of every day the sprint backlog task has been worked on.  The estimate is the total estimated hours remaining, regardless of the number of people that perform the work.

Increment

     Product functionality that is developed by the team during each sprint.

Increment of potentially shippable product functionality

     A completely developed increment that contains all of the parts of a completed product, except for the Product backlog items that the team selected for the sprint.

Iteration

     One cycle within a project.  In scrum, this cycle is 30 sequential calendar days or a Sprint.  Companies can tailor this to their needs.  We currently use a 14 day Sprint.

Pig

     Someone occupying one of the three scrum roles (Team member, Scrum Master or Product Owner) who has made a commitment and has the authority to fulfill it.  Just like a real life pig, who likes to get dirty, think of the members of your team who like to get their hands dirty completing the work.  Compare this with people not in your team who wont be getting their hands dirty, they are known as chickens.

Product Backlog

     A prioritized list of project requirements with estimated times to turn them into completed product functionality.  Estimates are in days and are more precise the higher an item is in the Product backlog priority.  The list evolves, changing ad business conditions or technology changes.

Product Backlog items.

     Functional requirements, nonfunctional requirements and issues, which are prioritized in order of importance to the business and dependencies and then estimated.  The precision of the estimate depends on the priority and granularity of the Product backlog item with the highest priority items that can be selected in the next sprint being very granular and precise.

Product Owner

     The person who is responsible for managing the product backlog so as to maximize the value of the project.  The Product owner represents all stakeholders in the project.

Scrum

     Not an acronym, but mechanisms in the game of rugby for getting an out-of-play ball back into play.

Scrum Master

     The person who is responsible for the scrum process, its correct implementation and the maximization of its benefits.  All round genius :)

Sprint

     A time-box of 30 sequential calendar days during which a Team works to turn the Product Backlog it has selected into an increment of potentially shippable product functionality.  This means that a team must aim to have potentially releasable software by the end of their sprint.

Sprnt Backlog

     A list of tasks that defines a Team’s work for a sprint.  The list emerges during the sprint.  Each task identifies the story being worked on, those responsible for doing the work and the estimated time remaining on that task on any given day during the sprint.

Sprint Backlog task

     One of the tasks that the team or a Team member defines as required to turn committed Product Backlog items into system functionality.

Sprint planning meeting

     a one-day meeting time-boxed to 8 hours that initiates every Sprint.  The meeting is divided into two 4-hour segments, each also time-boxed.  During the first segment, the Product owner presents the highest priority Product Backlog to the team.  The Team and the Product owner collaborate to help the team determine how much Product Backlog it can turn into functionality during the up and coming Sprint.  The team commits to this Product Backlog at the end of the first segment.  During the second segment of the meeting, the Team plans how it will meet this commitment by detailing its work as a plan in the Sprint Backlog.

Sprint Retrospective Meeting

     A meeting time-boxed to 3 hours and facilitated by the Scrum Master at which the Team discusses the just-concluded Sprint and determines what could be changed that might make the next Sprint more enjoyable or productive.

Sprint Review Meeting

     A meeting time-boxed to 4 hours hours at the end of every Sprint at which the Team demonstrates to the Product Owner and any other interested parties what it was able to accomplish during the Sprint.  Only completed work will be demonstrated.

Stakeholder

     Someone with an interest in the outcome of a project, either because he or she has funded it, will use it, or will be affected by it.

Team

     A cross functional group of people that is responsible for managing itself to develop software every Sprint.

Time-box

      A period of time that cannot be exceeded and within which an event or meeting occurs.  For example a Daily Scrum meeting is time boxed to 15 minutes and terminates at the end of those 15 minutes regardless.

Taken from “Agile project Management with Scrum” by Ken Schwaber with some personal touches by myself :)

Allan