Over the years in coaching, I have been using a lot of games. Most of these games are what I have learned by being with other coaches, going to conferences etc. There is a lot that can be done with teams by playing games. We learn a lot by doing it:) rather than reading about it:)

Do story point relate to complexity or time:

This article on infoq talks about story point and its relation to complexity or time. The argument seems to be it should be only related to effort and not complexity

When team members say Extra large for a story, generally it can mean one of the following.

a) I don’t have all the information needed and hence I think it is large ( This is not complexity or effort. This is the ambiguity or uncertainity. In this case we cannot really base the size on Effort as effort can only come to play when the team member knows that he or she needs to do

b) I know all about the story but this is complex. This is a good case to say this is complexity or more so effort. Its going to take me 10 days to do it as an example.

Story sizing is all about relative measure.

The real effort only comes to play when you work on story. At times what is a small story becomes extra large , the effort grows. So there should be not be a correlation to time alone. If we did time alone then why do we have to do task breakdowns.

Estimate size and derive duration. This picture captures the intent.
]]> http://agilefaq.net/2010/07/09/story-point-and-thier-related-to-complexity-and-uncertainity/feed/ 0 vibhu Story point http://agilefaq.net/2010/06/11/does-csm-certification-make-a-good-scrum-master/ http://agilefaq.net/2010/06/11/does-csm-certification-make-a-good-scrum-master/#comments Fri, 11 Jun 2010 13:33:32 +0000 editor http://agilefaq.net/?p=322 ]]>

I have been reading lots of discussions around the Scrum Alliance and its certification process. Does taking a two class make you a good Scrum masters? For an answer to this question, I asked some of my friends who have been great scrum masters.

The general opinion was that while the CSM class does give the basics of Scrum, it completely misses the ball on the “Human factor” involved in being a good Scrum master. Some of the best scrum masters seen are not certified but certification does help. The great thing about the CSM class is the interaction with others much less the certification part. Many times scrum masters learn by doing trial and error on Scrum basics and in doing so they end up causing a lot of damage to the team.

By going to a CSM or for that matter any training class , the interaction with the instructor and others in the class will get you going on the basics. I am an Agile coach and often play the role a scrum master. The toughest part in being a scrum master is not Scrum, it is being aware of what to do and what not to do in a team.

Every time I take the role of a Scrum master and coach Scrum masters, I always tell them not to apply the same rule to every team. Each team you will facilitate is different. As far as certifications go they are a nice to have tool , but that should certainly be not the criteria to hire a scrum master.

Along with it try to see if they pass the CFROC Test.

Are they committed to the team, Can the keep the focus on Scrum and distance themselves from the politics, Can they respect themselves and thier team members,
Are they open enough to help the team with whatever the team needs without taking any sides, Are they courageous enough to stand up to the team and protect them.

BTW this is spoken about in the CSM, but leaning and doing are two different things.

But if you have teams that are face to face or teams that are distributed but are essentially seperate teams then you do not need anything more than a physical board.

Here is a version of a manual board

From PublicAgile

You can get this by downloading this template and then go to Fed Ex Kinkos to print and get it mounted on a large board. Costs you  around 80 dollars.

Read this article for more information on Metascrum, who should attend and how to run it.

Large products have many different feature lines or initiatives each of which may have one or more product owners.  Clearly there is more work and a lot of time that needs to be invested in keeping the product backlog for your product.

A product owner teams is  a scrum team with many product owners often with some developers and testers that meet many times a week to talk about a product backlog , meet customers. Think of this team as a group of fitness instructors in a gym who also need to work out in order to keep you in goods shape.

This document outlines more details about how to set up product owner teams

$\{CompanyName}
\{ProductName}
\trunk
\docs
\lib
\build
\src
\. . . { project folders }
\database
\test
\. . . { project folders }
\tools
\. . . { project folders }
\target
\releases
\tools

{ CompanyName } –This is your root name of your company, brand of product.
{ProductName}

trunk– This is the root branch, where new feature development will occur.This is where all developers will check in on a daily basis

trunk/src – All source goes here.

trunk/lib– This folder contains binaries, jar files referenced in test projects, as well as support applications (
junit.jar, nunit.framework.dll, nant, ant.jar)

trunk/build — This folder contains support scripts necessary to build the main branch.Also here is where you could store your build scripts for continuous integration.

trunk/docs — This is where any necessary docs per definition of done will go.

trunk]database — This folder contains all versioned SQL scripts needed to build the various databases.

trunk/test — This folder contains all test projects will go. You may want to keep unit tests here or with the source tree and then just exclude it from the release build.

trunk/tools — This folder contains all projects that are support tools, such as command line utilities.

trunk/target — Source from all the internal projects in source should compile to a common target folder.

/branches — This folder contains release branches, which will be branched from trunk for every release.

/tools — This folder contains any utility applications and scripts.

Download here

Here is an example of one such statement

“ As scrum masters of , we are servant masters enabling teams to deliver business value in the software we develop, protecting teams from external interferences, resolving impediments that teams have and coach teams in better ways of achieving software agility”

Our core values are

- Passive listening
- Respect
- Courage to speak up
- Be compassionate and help team member be better at what they do.
- Always find new ways to improve.
- Remove impediments that team members have.

Teams use different sizing techniques

T Shirt Sizing

X Small, Small , Medium , Large , Xtra Large

or

Coffee Sizing

Small, Tall, Grande

You can pick any sizing technique. Make up one if needed.

This is mainly done as we as humans and as managers are better at abstract terms. If we use hours as a way to size stories,then the managers in the room have questions, teams dont immediately feel comfortable with hours.

Sizing keeps the planning meeting at a fast pace.

A general measure you can use  for T Shirt sizing is how many days it take to complete a story

Small story –  1-3 days

Medium – 3- 5 days

Large – 5 – 7 days

X Large > 10 days

In order to convert a story size to a number you can use either factorial, Fibonacci or Squares.

Sizing Techniques

If in  a sprint your team does two small stories and two medium  then your velocity is 9 * 2 + 4 * 2 = 26 ( if you are following the squares techique). Square is simple and works quite well.

You can have stories that span multiple sprints, that may not make it to production. This may be part of a larger EPIC story. The goal is to work on it every sprint. We have seen many instances where the product owner decided to ship the story half way through that process, as they see see that what is developed so far is not complete, but is good enough to ship.

The intent of the story is to understand the actual story better Example: Investigate a build vs buy option Write some code that gives you enough confidence to understand the complexity involved in building a robot. Compare options example you may write some code to compare different OR mapping layers like Stored procedure, Hibernate , Object databases etc In the end estimation is always a guess. You can never be perfect You will get better at it as your team works together on that domain for a a while.

Say you are a member of a scrum team where there are  8 members , and you are following a two week Sprint.

So initial estimate of every team members capacity is  80 hours i.e. two weeks.

Some of the best scrum teams in the world work at 70 – 75 percent capacity. What that means is in the eighty hours they are at work, they would have to attend to company emails, go to meetings that are required at a company level, take lunch breaks, go on sales call etc. If you have another project then instead of 70 percent you only account yourself at 60 percent capacity. When many teams start with Scrum, we recommend them to start at 50 percent capacity. The other 50 percent accounts for day to day activities in your company.

Say your team is doing 50 percent capacity. That means each person in a two week sprint is only accounted for 40 hours. Out of which if you have a vacation day 8 hours, you take off 4 hours (The rest 4 hours you can account to the fifty percent)

Take a hypothetical example for a two week Sprint of a team at 50 percent capacity ( as this is a fairly new team to Scrum)

This team is made of Charles, Mike, Annie, Bob and Ray . Plus a scrum master. We don’t count the Scrum master’s hours in Scrum, unless they are pulling tasks off the task board .

Mike is there for both the weeks =  40

Charles has one day he is not there = 36

Annie is a part timer and she only works three days a week. So her capacity is 24 hours

Bob = 40

Ray = 40

Team Actual Capacity = 40 + 36 + 24 + 40 + 40 = 180 hours.

If the team worked all the two weeks at 100 percent capacity the would have a capacity of 8 hours a day * 10 days in a sprint * 5 team members = 450 hours.

See the difference of what is used in Scrum  and the theoretical 450 that now one can work. That is what provides the cushion and allows for the team to provide a sustainable pace in every Sprint.

Teams take a while to form and norm. They also make a lot of mistakes and tend to work a lot harder in the beginning.  Remember the Agile priciple

Simplicity–the art of maximizing the amount
of work not done–is essential

Teams take a while to master this. Once they have this and resoved team forming, norming, that would be a good time to start comparing them with others.

One of the main tenets of Scrum is “Sustainable pace”. Scrum teaams are able to get to this sustainable pace as they get really good at delivering something in a short span of time ie, 2 or three weeks.

Velocity cannot be precicted well if the Sprint length changes. If you think changing 2 to three weeks is going to help you, you are mistaken. The team will only end up signing of for more work than they normally would. Hence the problem has really not gone away.

Use cases tend to be a written level contract ( sometimes ) too detailed, sometimes not. There are typically few main sections to a use case. A use case Summary, actors, main scenario, alternate scenarios

There is no one to one mapping of a use case to a user story. Summary is like a story defintion. A use case can break into many small stories.

The main scenario in itself is a story with the actual line items in a main scenario becoming the acceptance criteria. The alternate scenarios become either thier own stories or in some cases simply acceptance criteria.

Both use cases and user stories are as good as the effort put in to write them. Both can turn fairly quickly to a rather mundane and useless document.

Here is an example of a use case broken into stories and acceptance criteria.

USE CASE FORMAT

Use Case Number -1

Actor – Bank customer
Summary - Customer withdraws dollars from his / her bank account.

Main Scenario

1. Customer inserts debit card into an ATM machine
2. ATM machine asks for a four digit pin
3. Customer enters the pin
4. ATM machine verifies the pin and it is valid
5. Customer enters the amount
6. Since there is enough bank balance, ATM dispenses the amount and debits the account.
7. ATM gives the card back to the customer
8. Use case ends.

Alternate scenario

4a) Four digit pin is invalid, ATM machine gives an error and asks the user to retry.
6a) There is not enough balance is the account. ATM machine gives a corresponding message

USER STORY FORMAT

As a customer i want to withdraw some dollars from the shop so that I can buy things i like.

Acceptance Criteria.

1) The customer should be able to enter a pin number. IF the pin number is vali the system should prompt the user for a dollar amount to withdraw.If the pin numer is invalid or there is not enough balance the sytem should show a error message.
2) If there is enough balance the system should dispense the cash and debit the account.

As noticed in the example a user story is converstional and conveys the same thing a use case does. It is a small card , with a conversation that is the acceptance criteia.

In case you need to use use cases use the use case as a start and break them down to stories. If done well, stories should be enough detail for the team to develop the system.

If the team is really not empowered to get the job done, that will bring the system down. You know that the team is not being empowered when each team member does not take responsibility or stays shy of taking decisions. If they always look up to the scrum master or dev lead. If a chief architect walks in a spoils thier plan and no one in the team is empowered to speak back. Telling teams and letting them know that thier destiny ( by which i mean ), how they want to work in the project is completely up to them. Team should get a lot of help in the beginning from experienced coaches. This saves a lot of time wasted later.

TEAMS MAKE OR BREAK AGILE COMPANIES

Leadership Role Responsibility of Role

1. Instructor Answers Questions and Supplies Data
2. Follower Provides Support and Encouragement
3. Coordinator Links and Integrates Data
4. Peacemaker Works for Harmony and Compromise
5. Gatekeeper Maintains Working Agreements and Discipline
6. Monitor Makes sure relationships are working
7. Pioneer Asks questions and Seeks Data
8. Influencer Initiates working agreements and team culture
9. Commentator Explains and Analyzes Data
10. Promoter Helps and Encourages Quiet Members
11. Critic Evaluates and Analyzes Relevant Data
12. Reviewer Periodically Checks and Corrects
13. Devil’s Advocate Deliberately looks for alternative and oppositional views

First Person:

I am a firm believer that the velocity is set by the team (not
management, not Scrum Master) as a measure of how much value they are
able to deliver based on yesterday’s weather and the team’s
capacity/ability at the time.

It’s an easy trap for management to use velocity as a measure of
productivity and assume that if they increase it a little more each
sprint the team will deliver more with the same quality.   That is a
myth.  The team should demonstrate that the velocity is based on the
best we can do given our current capabilities and knowledge we have at
the time.  If there is expectation that they should do more, the
discussion needs to change to impediments that are keeping the team from
delivering more value.  Taking the discussion this way will encourage
the looking for waste and inefficiencies that could be improved or
removed in order for the team to be able to deliver more.

Increasing velocity will not motivate.  If anything, it will cause the
opposite and that the team is being asked to do something they aren’t
able to do on their own and really commit to.  This causes frustration
and breaks down the trust/transparency between management and the team.

Second Person:

The bottom line…You spend something each iteration and that is a function of time, cost, scope and quality.  Fixing time and cost and increasing scope is unreasonable.  Over time, with more maintainable code, better domain knowledge, improved team competencies and better infrastructures will increase velocity.  Most other attempts (except removing people from multiple projects) will usually spend quality. Quality is spent either by reducing product quality or the teams’ quality of life.  Overworking people can have short spikes of productivity (a week or two) but statistics show that people working 12 hours per day are no more productive than 8 hours per day within 3 months.

From a lean perspective, more items will increase waste.  Also, overloading teams causes an overpressure on the teams.  If this were a pipe, the pipe would burst (sending caustic chemicals into the environment with long standing and expensive problems).  Unfortunately, people are much more adaptable than a pipe and so the indicators of emergent problems is harder to recognize until too late.

http://www.scrumalliance.org/articles/14-technical-debt-and-design-death

Third Person:
My suggestion (which has passed no orthodoxy test) is to stay close to
recent experience, and maybe set some reasonable stretch goals IF your
team is building coherence and effectiveness as sprints go by, or are
coming back from a difficulty, or are enthused and excited, or some
situational impediments have been relieved, or they recognize a need to
push some for the sake of the customer relationship. I think you have to
be very sensitive to reading the team psychology – their relationships
with each other, with you, and with the customer. In any case, I think
the team would have to sign up for any stretch goal, rather than having
it imposed by you, or god forbid, by the customer.

Fourth Person:
We have found that signing-up for less lowers the pressure and raises the confidence then the team actually does more than the stretch goal that if attempted always works against you and you deliver less.

Fifth Person:
My experience with stretch goals has been that they have four fundamental flaws:

1) There’s no good way to represent them in Agile planning and tracking tools/data.  If you fully flesh them out with task estimates and plan estimates, then you’ve potentially wasted that planning time (if you don’t get to them), and you’ve distorted your burn-down graph.  In particular, this often leads to quality loss and short-cutting in the first few days of the Sprint as people see that the burndown slope isn’t converging to zero, but don’t realize why.

2) They cause stress and distress to the team.  “Everyone knows” that management half-expects the stretch goals to be met, and yet if we-the-team were confident of meeting them, they wouldn’t be stretch goals, they’d be part of our velocity!

3) They cause bad customer expectations and bad feeling between the development team and the customer.  In every Agile project I’ve worked on, if we gave the customer a stretch goal, the customer inevitably asked at the end of the Sprint, “Well, why didn’t you get the stretch goal done as well?”  The answer, “Because it was a stretch goal”, while entirely accurate and fair, never seemed to satisfy them.

4) Stretch goals are redundant.  We have, at least in theory, a prioritized Product Backlog.  The ScrumMaster and the Product Owner should be collaborating on an ongoing basis to ensure that at least the top 20% of that backlog is current, ordered by priority, well-understood, and ready for inclusion into the next sprint’s Sprint Backlog.  Well, there’s your stretch goals, ready-made and already in priority order.  If you happen to finish a sprint early, at a sustainable pace, and with optimal quality standards (the only time you should ever be looking for a stretch goal at all), you can go directly to your Product Backlog, take the top-most item, and voila, you have a stretch goal.  Negotiating explicit stretch goals with the customer obscures this resource and increases customer confusion about the role of (and importance of maintaining) the product backlog.

For these four reasons, I strongly oppose the use of stretch goals in Agile planning.  Agile already has better solutions to the problems that stretch goals nominally address, and these better solutions are far less likely to cause poor customer communication and team distress.

This is a standup, so don’t sit.

At a high level:

• Is the project in production?
• Is the product producing revenue?
• How long since development I could get the product to generate revenue?
  • Sometime agile products iterate for a very long time and when finally released end up looking like a waterfall effort.
• How much did i spend in developing a story point or a use case?
• What was planned and how much did I end up spending?
• Is the product in a decent shaped to take it to market?
• How often has the team delivered value?
  • One of the key aspects of agile development is to pick stories that provide value to the business from very early on. It is critical for the success of agile projects that there is a balance of stories from just a feature that enhances a functionality to one that can generate revenue.
• Number of level one of two defects?
• Are all the stake holders satisfied?
• What are the customers saying?
• Have we increased the customer response time?

When working with stories from a product backlog especially during release planning, Write all the epic stories ( the main use cases ) and instead of stank ranking them numerically, apply the

• Must Have,
• Should Have
• Could Have
• Wont Have

rule to each story . i.e. ask the product manager to write a M S C or W in front of every story. Sometimes product owners find it tough to apply numbers but a grouping like this is much easier for a first pass.

But key architectural / design issues should be verified using spikes or conceptually to some extent, to to address key tenets of architecture like layering, tight coupling, scalability, testablity etc.

Agile teams esp XP teams consisting of senior developers can pull off with Just in time architecture. But in most cases the team consists of a mix of developers and to expect every member to contribute to the evolution of architecture is a challenging task. 

An architecture vision and some detailed archicture analysis ( may be for a sprint or two) is good  for the overall health of the system.

http://www.agilejournal.com/articles/articles/scaling-agile-development-via-architecture.html

Product owner is the the hub of the scrum team. They can make or break the team. The reason for this is that they hold the key to the story box. They are the visionaries ( sort of a product manager). At times they are also proxying for others. Many scrum projects fail solely because the product owner did not perform his role well.

The important functions among others of a product owner in no particular order are:

1. Own the product backlog and in doing so the check book.
2. Be the sole voice for requirements that the team can trust.
3. Be the mediator to other interested parties in the organization and allow other stake holders to make thier case
4. Communicate with the management on the status of the project.
5. Be the main anchor in a sprint planning meeting.
6. Prepare the backlog every sprint for the next sprint or so. Capture lots of detail for the upcoming stories while thinking a bit about the stories for future sprints.
7. Be able to articulate what it would take for a developer so that he /she can accept the story as done.
8. Do bug triaging.
9. Train the users as the visionary of the product.

This is a simple document which can be changed every iteration or sprint or necessary. Anything goes here that all developers agree.

Common things added in this list are:

1) Core time that the team members will be present. In case of a distributed team this would define the core overlap time the distributed teams will meet

2) Time of stand up.

3) How much pairing hours are considered good. An ideal pairing day could consist of any where from 2 – 6 pairing hours for example

This document is visited every interation and changes are made. This is one of the visible indicators that should be in the area where the teams are working.

Here is an actual example of one such document from a highly productive scrum team

1. Tell the Truth.
2. Use the Impediment Backlog for blocking issues
3. Address any issues to the correct party (at the right time).
4. Meetings: Be on time, end on time, have an agenda
5. Communicate individual schedule
6. Use sticky note on monitor, email, phone call, etc.
7. Update backlog before SCRUM daily
8. Be present for core hours: 10:00AM – 5:00PM
9. Communication – to the best of our ability
10. Publish phone numbers & Calendar
11. SCRUM is at 11:00AM Pacific Time
12. If unavailable for SCRUM, communicate status
13. Test Driven Development is a requirement for the project.
14. Pairing or code reviews are required for any shipping code
15. Part of requirements for DONE criteria
16. When pairing, turn off distractions (email, IM)
17. Define and adhere to DONE criteria for stories
18. Record Accurate (actual) hours
19. Define and adhere to Version Control rules
20. Don’t break the CI build!

In simple terms its a number that tells the team how hard the story is.

In most cases a story point range is

1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large

It is a relative term and does not directly co relate to actual hours . Since story points have no relevance to actual hours, it makes it easy for scrum teams to think abstract about the effort required to complete a story.

This also creates a lot of confusion as most scrum masters who come from a PMP background relate this immediately to hours.

Story points do give some indication of how much time time was spent in a sprint.

Example lets say at the end of a 10 day sprint a team of 4 covers 40 story points.

10 days = 10 * 8 working hours = 80 hours. = 320 total hours as there are 4 developers.

That equated to 160 pairing hours.

160 divided by 40 =  4 hours pair hours per story point.

Velocity is a measurement of how much the team gets done in an iteration ( called as Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is planned.

In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

Examples are 1, 2, 4, 8 , 16

5, 10 15 and so on.

A story depending on its complexity is given certain story points. So if the team does 6 stories that are 8 story points that iteration , the teams velocity is 48 story points.

KISS in Agile stands for Keep it simple Stupid

This applies to everything from planning, to design to development.

Do the simplest thing possible.

Don’t make it up.

Keep it simple