Story point and their relation to complexity and uncertainity

This article on infoq talks about the 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 uncertainty. 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 the relative measure.

The real effort only comes to play when you work on a story. At times what is a small story becomes extra-large, the effort grows. So there should 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.

Does CSM certification make a good Scrum master?


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.

What is a mission statement for scrum masters in a company?

If you have multiple scrum masters in your organization, it will be good exercise to come up with a charter for your group.

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.

What are different ways to size stories? Why do we do story points, not hours?

MIke Cohn talks a  lot about this in his book Agile Estimation and Planning. You can use any measure to size stories.

Teams use different sizing techniques:

T-Shirt Sizing

X Small, Small, Medium, Large , Xtra Large


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
Sizing Techniques

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

How soon can we see improvements when we start using Scrum?

Managers , take it easy. In many organizations there is an urgency to measure, look at numbers as they move to scrum within the first two sprints. As a general guideline, do not take too much notice of the statistics for four or five sprints.

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.

Can we change the length of a sprint?

This question comes up a lot in new scrum teams. The adjustment from a couple of months to two weeks is very tough indeed. Generally speaking do not keep changing the sprint length. One Sprint two weeks, the next three weeks etc.

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.

Be Aggressive with Velocity

We asked a bunch of Agile experts what is their thought on velocity? Here is the question

Should we select a velocity conservatively based on history vs. setting an aggressive velocity to encourage more productivity?

Here is what we heard

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 an 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, 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.

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
the 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 feelings 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 the 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.

What is Moscow Rule In Scrum?

Moscoq MoSCoW rule

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.

What is the most important role in a scrum team?

Unquestionably this is the product owner.

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.

What is a team ground rule or team working agreement

Working Agreement of a software teamagree.jpgBy definition an agile team has a high amount of daily interaction. This brings out a need to establish some common set of rules that all team members abide by.

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!