It is a thing called scrum and
this is how it is done.
We talk and discuss
Then we create a product backlog without fuss

A backlog has many items , they call each one a story
and its not a document thats gives the author 400 pages of glory.
On our backlog we keep it simple, non-ambigious and plain
and this way everyone remains relatively sane

A story is a simple statement that tells us to talk more
It lets us collaborate rather than document pages up to four
The story states the fact and is easy to understand
Its not something that is confusing or grand.

For each story We ask for simple criteria on what our customer will accept
this removes long paragraphs that are confusing and inept.
So when you see it and go “oh now I see”
You wont ever want a big document again from me.

The backlog is simple even executives can read it without pain
The backlog for our customers so much to gain.
So once they see its effective way
Most of them go specs, get rid of it I say.

Each item on the backlog proritised so high value first
We work on these in order so we satisfy our customers thirst.
The customer can change their mind, they are realising what they need
And for us we embrace it, it means their project does not bleed.

So we hold a meeting and all of us talk, collaborate and share
we decide what can be done from the backlog, as we care.
We decide what is feasible and what can be done
We select the challenge and know this will be fun

So our team we commit to deliver features in a set time
its called a sprint or iteration and it works just fine.
As the team choose what and how we give you a result
we just ask you trust us, dont interrupt and cause insult.

Every day we have a meeting
We unfortunately dont provide any form of seating.
We only let those in who are accountable and care
Any intruders well for them they may get a stare.

From our daily meeting we highlight what is blocking us or making us slow
Then those with the responsibility to solve it off they go.
This lets the team carry on and produce working software
This lets your project keep moving, as we are always aware.

We use the best practices decided by the team
We talk, share , have fun and strive to our customer’s dream.
At the end of this time we show what we have done
We always give you something that can potentially run.

At the end of this iteration we have a restrospective meeting
this time we do provide seating.
We sit down and think back to what went right, what was not efficient
then we produce actions to improve us and not make us deficient.

The next time comes straight away and we start it all again
And each time we learn and as a customer features you gain.
And your product comes to reality and you see it emerge
and now you know why you have value and you did not have to splurge

An effective scale to use for your estimation is T-Shirt sizes.

T-SHIRT SIZES

Size                                    Points to Allocate

XS (Extra Small)                   1
S  (small)                                2
M  (medium)                         4
L  (Large)                               8
XL (extra large)                   16
XXL(extra extra large)       32

T-Shirt sizes are nonlinear so the bigger the “shirt” the larger the gaps become between the previous size. This “gapping” allows us to take into account that the bigger the story the more “unknowns” exist.

The points are also relative for example:

• a large story is twice as big and complex as a medium story
• a large story is 4 times bigger than a small story

A developer that is not willing to embrace agile should not be placed on your team, even a single doomsayer can cause major negativity, disruption and resistance to change. Pick a motivated team that is keen to embrace change.

A CIO who is a heavyweight fanatic is not going to be much help if you are trying to implement scrum

Ensure that the team is empowered and trusted to get the job done and that they are allowed to learn from their experiences

Do not think that scrum is a silver bullet and that on day one everything will miraculously fall into place.The framework and practices are simple and efficient but any change is difficult. It requires dedication and effort and this does not occur overnight, those that persevere will succeed. Give it enough time to witness the benefits.

Ensure that there is a mentor or coach with the correct level of knowledge so that they can guide the adoption of scrum. If you cannot find one locally and you are serious about it then inject extra funding to bring in an expert, its a small price to pay.

Ensure that all those responsible understand scrum and its principles and why things are been done differently to Waterfall and other methods

Ensure that stakeholders, sponsors, business representatives and customers are available for collaboration and feedback. If they are not then appoint persons who can be available, this is essential.

Forget about old habits and how we used to do things. Big Design Upfront (BDUF), Big Requirements Upfront (BRUF) and BPUF (Big Planning Up Front) don’t fit into the scrum framework. These are all anti-patterns.

Inspect and Adapt, ensure that the team and all parties are continuously improving, realise that each project or product is different.Scrum is a framework that is empirically based and allows you to adapt and improve within it.

Ensure that there are dedicated resources. Do not spread resources across multiple projects

Where possible try and co-locate the team. If this cannot be achieved then take advantage of technology and get as close to this as possible through virtuality e.g. video conferencing and individual web-cams

Ensure that the stakeholders, sponsors and customers manage the return on investment (ROI) through value prioritisation. This requires all parties to embrace changing product requirements

WHY 4 WEEKS?

Scrum recommends that iterations do not exceed 4 weeks. I have heard of some implementations using 6 weeks. I stick with durations of 4 weeks or less.

4 weeks of fixed scope is not too much and it does not overwhelm our customers, stakeholders and team members with huge amounts of information. Our feedback for an acceptable amount of work is manageable. We can focus on a small the amount of work to achieve our outcome and deliver this to the highest level of quality. If we had iterations of 3 months we introduce to much complexity and unknowns, the horizon is too far off.

Fixing a defect on 4 weeks of work is much different in cost and complexity to fixing a defect on 3 months of work. 3 months will most probably result in more defects anyway.

FIXED Vs VARIABLE LENGTH ITERATIONS

I have seen and fixed an agile implementation where the iterations started off fixed but ended up variable. This is a bad practice and should be avoided at all costs. Software product development contains so much variability and hidden unknown nasties. Adding another dimension on variability is just going to make things more complicated and painful.

“Oh its just another week and we can get these 2 done”

“I know we have added 2 weeks to the iteration, its been 6 weeks now but really one more week wont hurt to just get these 2 new stories done, they are very important you know”

So this goes on, rinse lather,repeat.

Variable length iterations guarantee behaviour where stories will be added to the iteration because it allows it, resulting in:

• the iteration deadline and scope moving on a regular basis
• disruption to the team and their committment to get work done, “aaagh I just want to achieve our goal, now more work, i did not commit to this, we need to have a meeting as we need to estimate this now”
  disruption to planning and meetings e.g.

“oh sorry no we are not finishing Friday we are now finishing next Friday, ill re-schedule the retrospective meeting”
“I know the product owner accepted but the meeting has changed to next week, oh is he in London next week?”
“No we cant demo when we said we have added another week”

• an increase in the amount of scope that the team must focus on
• forcing the iteration goal to constantly change within the iteration
• making productivity metrics more complicated than they should be

With a fixed duration we never miss the deadline, the time never moves, if productivty is affected then and only then do we remove work or add work and slightly adjust the goal, but we never miss our deadline. This gives the team a good feeling of always achieving something. As time passes the team will begin to get a natural feel for the capacity of work they can do in a timebox and their estimation will become more accurate.

Fixed iterations simplify planning and reporting, especially velocity. If we have consistent 4 week iterations then we dont need to adjust velocity. The only option we have is to use yesterday’s weather for planning, its the last bit of fact we had.

For example:

Iteration 1 4 weeks Velocity = 30 points
Iteration 2 1 week velocity = 12 points
Iteration 3 3 weeks velocity = 20 points

Iteration 4 is 4 weeks long so how many points are we going to use to select the initial stories for the iteration, cant use 20, now we have to come up with some calculation dont we, keep it simple:

Iteration 1 4 weeks Velocity = 30 points
Iteration 2 4 weeks velocity = 34 points
Iteration 3 4 weeks velocity = 48 points

The reason why iteration 3’s velocity has improved is that the team is becoming very knowledgable in the technology and product , productivity is increasing.
So for Iteration 4 lets select around 48 points of work for the iteration planning meeting.

RYTHM IS NOT JUST FOR THE TEAM

A constant iteration cycle gives our team, customers and stakeholders rhythm in knowing when iterations are finishing and starting. Every 2 weeks the stakeholders or business get to see working software, every 2 weeks they get a product burndown chart. Every 2 weeks we re-adjust the plan, the release, the communication to sponsors, finance and executives etc. Every 2 weeks they get a realistic picture on how the product is evolving and can continiously make decisions based on fact.

“Its the end of another iteration on Tuesday, thats great we will see some more working software.” Can you imagine a situation of “How long is the current iteration? when does this one end?, Oh is this one 4 weeks. Why was the last one 1 week?”

Iterations of the same duration simplify:

Resource Planning
Financial Planning and Budgeting
Release Planning
Meeting Invites
Productivity Metrics
Reporting

PRIORITISATION OF WORK, WE DONT WANT TO WAIT TO LONG

Product requirements will change and priorities will change. While the team is progressing during an iteration, if a high value item is realised then the business only have to wait the remainder of the current iteration before it is worked on, and this is acceptable. Its not a long time to wait.

Imagine a scenario where:

Iteration 1 is 2 weeks
Iteration 2 is 1 week
Iteration 3 is 4 weeks

In Iteration 1 our stakeholders re-prioritised a product backlog item as high value and were told that we will be working on the high value item in 2 weeks.

On day 2 of Iteration 2 our stakeholders realised a new high value feature and were told it would be worked on next week.

In Iteration 3 they had to wait 4 weeks. On each occasion they were given a different answer.

MULTIPLE TEAMS

Consistent duration between multiple scrum teams makes synchronisation and integration far easier. Imagine the following:

Team 1 (The bad team)

Iteration 1 - 2 weeks
Iteration 2 - 1 week
Iteration 3 - variable

Team 2 (The good team)

Iteration 1 - 4 Weeks
Iteration 2 - 4 weeks
Iteration 3 - 4 weeks

How are these teams going to:

synchronise work and releases
integrate streams
rebase code
report on overall progress

Fixed iterations of the same duration provides rhythm and consistency to all areas in the product development cycle and fosters a common and simple understanding for all parties be they Stakeholders, Customers, Sales and Marketing, Finance or members of the product development team.

ScrumWorks

XPlanner

Target Process

Microsoft Scrum for Team System

Banana Scrum