Thursday, October 13, 2011

Pair Programming Jokes

Ok, I have only one, but it is a goody.  Especially told by a guy named Arkadiy who delivers this with a Russian accent.  If you know more jokes, please add them into the comments.
 
Dude, dude, refactor
Two drug addicts are driving down the road.  Suddenly one of them says, "Dude, dude, watch out there's a bird," and the van drives over it. Later, he says, "Dude, dude, slowdown, there's a cat," but they run over the cat too.
Then there's a dog and the guy says, "Dude, dude! Lookout, there's a dog."
The other guy says, "Dude, you look out.  You're the one driving."

Tuesday, September 20, 2011

Developing Organizational Standards to Support Agile Teams

Abstract
At the department level, Agile processes are less descriptive on how to increase delivery excellence across all their teams.  One approach is to provide implementation-free constraints/goals that drive teams to better delivery and then encourage a culture of cross team information exchange.  The constraints/goals will create direction and incentive for teams throughout the organization, while information exchange at the team level allows new 'best of class' solutions to these constraints/goals to propagate across the organization.  By inserting a few organizational standard items into  team Working Agreements, using Build Monitors to make quality visible, and learning events such as Book Groups, the organization can create a minimum "bar" across teams that will force some teams to improve their delivery excellence, yet won't get in the way of teams who already have good delivery excellence (yet potentially non-standard though innovative development methods).

Introduction
Most agile methodologies come with a built-in form of information exchange at the team level:
daily standup meeting, retrospectives, sprint demos, pair programing, planning meetings that include the entire team, retrospectives, and code reviews.  eXtreme Programming, for example, contains the most extreme form of team viral information sharing--pair programming, which has developers working with each other and improving all their development craftsmanship on a daily basis (including soft skills), but sometimes people can't get along with each other.  Other forms are lightweight and helpful, but reduced efficiency--code reviews, for example, help people become better OO programmers (a part of craftsmanship), but the practice increases work-in-progress, creates an additional future integration point (integration of design ideas), discourages code experimentation (might not make it past the code review), and doesn't help people learn how to use their software tools such as the IDE more efficiently.

Although most Agile methodologies come with good information exchange at the team level, finding how to direct efforts across the organizational is rarely discussed.  (Scrum has Scrum of Scrum and Meta Scrum.  Others practices?  Please use the blog comments to add more knowledge if you see something missing.)  Here are strategies that I've seen implemented to a good effect across an organization and creates a minimum bar of delivery excellence across all the teams, forcing some teams to discover better ways to deliver code, yet doesn't disrupt teams that already are excellent at delivering code.

Working Agreements
The best working agreements have fewer than eight items and are visible in the team's working area.  Here is Fred.  Off camera is the rest of his team.  Although this working agreement was developed by the team, organizational standards were incorporated without being "too" proscriptive.  This way, the team takes ownership of their "implementation" and use their own tools/processes to accomplish the working agreement.

Team Working Agreement
Teams get a lot of value by having a written agreement on how we work together and handle day to day issues.  This agreement often puts into writing the answers to the "typical" questions that non-self directed teams recieved by asking their project manager, "hey, this happened, what should I do?"  This working agreement is often referred to by the following names: Team Working Agreement, General Working Agreement, or Daily Working Agreement.  The editorial comments in parenthesis aren't explicitly written down on the working agreement, but are understood by the team.

Example:

Team Working Agreement
- Automated tests are added for all discovered production issues before the code is written
- Standups always include a dial-in (for teams that have remote team members/PO)
- solving production fires is top priority
- stop what your doing to address failing automated unit tests
- the state of all automated tests is visible in the team area
- all system tests, unit tests, UI tests are executed by CI
- all unit tests are executed at least daily
- comprehensive test passes are executed before release to live (all automated + manual)
- all code changes are developed using TDD (legacy code and new code)
- QA starts writing system tests on day one of sprint
- everyone is a tester

Organizational Standard
Setting some core standards across all teams about what few items must be in Team Working Agreement works well.  Common subset of the above that I've seen in practice are:
  • all system tests, unit tests, UI tests are executed by CI
  • all unit tests are executed at least daily
  • visible burndown chart
  • Scrum is practiced (this is usually implied)

Story Definition of Done       
This is the team's agreement on what "done" means when they say, "this story is done."  All the steps to the story being done must be met to get "credited" with the story being finished so the team can accumulate the story's estimate in Story Points/Units into the team's Velocity.  When the team starts a new Definition of Done, the SM needs to be vigilant until the team has got it.  If the team can't follow it, then we look for "why not" in the Retrospective and find some way to handle the impediment (fix some problems, adjust definition of done)  This definition of done is important for maintaining the team's standard of potentially shippable at the end of each sprint.  The editorial in the parenthesis isn't typically added to definitions of done but understood by the team.

Example:
Story Definition of Done
- All public methods are unit tested  (except for machine generated code that isn't changed by human hands, or DataValue objects that are "identity--I=I" getter/setters)
- Story functionality is tested with an automated system/UI test (also called acceptance tests, functional tests, ...)
- Manual tests are executed
- Rally is updated (Rally is an electronic story tracking tool)

Organizational Standard
  • all public methods are unit tested
  • stories have automated system tests (also called acceptance tests, ...)
Sprint Definition of Done  
Because a sprint is time boxed, the sprint is finished regardless of the "pass/fail" of the items in the Sprint Definition of Done, but the retrospective should be used to identify the root causes and create actions to solve problems.

Example:

Sprint Definition of Done
- Each sprint, the code coverage increases
- All automated tests are green at the end of the sprint
- All manual tests for the stories are executed

Organizational Core Standard
  • code coverage increases each sprint
  • design issues go down each sprint
  • automated test count (system and unit) goes up each sprint

Other Working Agreements
The following working agreements may also be useful to teams.  The art is to find the fewest agreements so we aren't buried by paperwork and yet have the ones that are necessary because problems happen when we don't have them: Task Definition of Done, Release Definition of Done (contains activities to be done before the software goes live, such as performance testing, security testing, or other things that for some reason, there are impediments to getting them done during typical sprints.)

Build Monitors
These devices show the "headlines" of the projects quality status.  Anyone can "click" for details.  This team modified the continues integration system's CSS to get the clear and simple style they wanted.  (Unfortunately, most CI environments have overly complicated dashboards.)  The monitor the left has the biz tier (unit tests) and web services tier (system tests) for the SAME app.  The build was split into logical levels.  The first level compiles, then runs unit tests for the biz tier, and then runs system tests for the web services tier.  The monitor on the right is the system tests that test the UI.  These three levels are common.  It's not hard to imagine adding a SQL level would be useful for a team doing work with stored procedures.  The success of one level cascades to the next level.  A failure at level one (can't compile) stops it all.

Book Groups
Books a great way to get information across many people in an organization.  Just buying everyone in your department a book is a weak play (I still haven't read "The HP Way" which was given to me by my manager when I started work at HP).  Books are great learning tools if they are actually used.  I don't recommend buying people books unless they ask for them or it comes with a plan reading and using the knowledge.  Book groups are groups that get together and discuss reading and using the knowledge (or actually demonstrating the knowledge).  To encourage the Cross Pollination of Information, find someone to start a cross organizational book group that meets each week over lunch (companies often buy lunch and the books, and if people are meeting about the books).  Encourage the group to develop activities to put the knowledge to work: get members to sign up to teach or demonstrate or lead discussion for each chapter of the book.  DO-CODE-ON-PROJECTOR with a mob watching is my personal favorite tactic.  Books I recommend are: Martin Fowler's Refactoring, Diana Larson's Agile Retrospectives.  Teams I've been a part of have done this with books on Refactoring, GOF Design Patterns, eXreme Programing Explained, and Java Concurrency.

Conclusion
Delivering to all your teams core standards for their working agreements creates quality bars that teams aim for and hurdle over.  If the organization focuses on the desired outcome and allows the teams to develop how to reach those outcomes, the teams will find solutions that work best for their personal and project makeup, and they'll become vested in the implementation.  Adding in collaborative cross-organizational sharing and learning events such as book groups that are driven by employees, will give the employees a process for driving their own development and collaborating/learning with other team members.  

Troubleshooting
Here is a troubleshooting guide that covers some common problems that may occur implementing the above activities.
  • Team finished sprint with zero velocity.
    • Maybe their working agreements were too hard.  Inspect and adapt for next sprint.  Maybe they need to embed a coach for a sprint.
  • Team releases with bugs.  
    • Not enough testing.  Zero bug releases are expected.
  • A team's CI environment isn't visible
    • Are their tests failing?  What are they hiding?
  • Team refuses to try new practices/process for even a sprint.
    • Too much release pressure?  Team embedded in their old ways?  Is the company culture so risk adverse that any failure has political implications?

References:
XP practices http://en.wikipedia.org/wiki/Extreme_programming_practices

Thursday, September 8, 2011

What do studies say about Agile?

Agile Studies
This is going to be a different posting.  This one will be organic and added to as I find other good bits of information.  I need something like this to make it easier to go over an inventory of studies.  I need this to solve my "searching for studies" impediment which comes up periodically.

Help me keep this up to date.  If you have an Agile paper you want cited, comment about it. 
Refactoring:
 Understanding the Economics of Refactoring
Abstract: A novel method for estimating the expected maintenance savings given a refactoring plan. This work is motivated by the increased adoption of refactoring practices as part of new agile methodologies and the lack of any prescriptive theory on when to refactor.
Lance's Summary:
  •  best to refactor code that is going to be changed a lot in the future, so pay attention to where your rate of change is and keep that code clean
  • a guideline is that your refactoring pays for itself after six times you needed to revisit the code and change it
Test Driven Development:

TDD Improves Quality
Abstract: A paper first published in the Empirical Software Engineering journal reports: "TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team." The study compared 4 projects, at Microsoft and IBM that used TDD with similar projects that did not use TDD.

Does Test-Driven Development Really Improve Software Design Quality?
David S. Janzen, California Polytechnic State University, San Luis Obispo Hossein Saiedian, University of Kansas
Lance's summary: TDD allows simpler design == less lines of code to do the same thing
Summary: Software developers are known for adopting new technologies and practices Software developers are known for adopting new technologies and practices

Test-Driven Development and Software Quality
Lance's summary: a blog that comments on the IEEE paper "Does Test-Driven Development Really Improve Software Design Quality."

Pair Programing:
A good summary about the practice along with a little satire at wikipedia.

The Costs and Benefits of Pair Programming
Alistair Cockburn & Laurie Williams

Lance's summary: Pair programing creates a lot of value over the total product lifecycle (higher code quality, lower defects, reduces team bottlenecks, and increases work satisfaction) at the cost of 15% more development time.

ABSTRACT
Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.


Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise
Erik Arisholm, Member, IEEE, Hans Gallis, Tore Dyba ̊, Member, IEEE Computer Society, and Dag I.K. SjĂžberg, Member, IEEE

Abstract—A total of 295 junior, intermediate, and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden, and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the programmer expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors. It is possible that the benefits of pair programming will exceed the results obtained in this experiment for larger, more complex tasks and if the pair programmers have a chance to work together over a longer period of time.

All I Really Need to Know I Learned in Kindergarten
By Robert Fulghum (Fulghum 1988)
Lance's Comment: Not really a study, but important information for people interested in pairing studies.  This paper contains a lot of the behaviors needed for successful pair programming.

Abstract:
Share everything.
Play fair.
Don’t hit people.
Put things back where you found them.
Clean up your own mess.
Don’t take things that aren’t yours.
Say you’re sorry when you hurt somebody.
Wash your hands before you eat.
Flush.
Warm cookies and cold milk are good for you.
Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.
Take a nap every afternoon.
When you go out into the world, watch out for traffic, hold hands and stick together.
Be aware of wonder.

Pair Programming Testimonials
Abstract:
If you would like to share your pairing experiences or read about other people's, this is the place. Describe the good and bad of your experiences pairing to help others in a similar situation - just a paragraph or two would be great . . . what worked well, what didn't work so well, what kinds of things did you 'attack' together, tips and tricks, etc. A great example of a testimonial is by Ron Jeffries in the July/August 2000 IEEE Software page 25.




Friday, September 2, 2011

The ONE right way to Scrum

What is the right way to Scrum?
This question is brought up a lot in organizations that are transforming to Scrum to improve their ability to deliver products. It's a natural question for smart people to ask when they are receiving Scrum training and then discover other teams adjusting from the "default" or "standard" implementation of their company's Scrum process.

Is there one way to do Scrum?

It's better to ask yourself, "should there be one way?"

When anthropologists talk of societies and biologists talk of evolution and virus colonies, history has shown that the results of monocultures are dangerous. The societies, governments, organisms, or colonies that survive are those that could respond to a change that wiped the others out. Having everyone thinking and agreeing all the time means new ideas aren't getting tried out. On the other hand, having only conflict/chaos means poor productivity/survival.
Computing monoculture
agricultural monocultures

What is Scrum?

Scrum has been around for over 10 years.  (You can read Martin Fowler's 2005 overview of Scrum in
The new methodology called Scrum)

Scrum says once the planning meeting has finished and the sprint starts, the planning conflict (conflict over resources) is over (or at least is moved outside the team) and the execution of the plan begins. For the team, conflict moves to technical implementation as they discover the best designs (test plans, class designs, craftsmanship) to meet the plan's goals. At the end, the team, ScrumMaster, and ProductOwner inspect the results and proposes a "new experiment" to improve software delivery.

What is Scrum (or basic scrum)

Three roles: team that does the project work, a ScrumMaster, and a single person to be ProductOwner.
A fixed backlog of work for a sprint.  A sprint is a fixed length of time.
A quick planning meeting.
Retrospective and sprint demo.
Daily standup meetings that are no longer than 15 minutes.

*Velocity, burndown charts, and task boards are also expected but aren't necessary for the empirical process other than adding more visibility. But since visibility is necessary, like a microscope is necessary to a biologist, I'm including them too.

You may ask six Agile Consultants "What is Scrum" and get six answers but I expect all six will have at least all the above.

Why six different answers?
How I Scrum today is different than how I Scrummed in 2006. How I Scrummed in 2006 is different than 2004 (my first Scrum project). But in all cases, I did Scrum. Before 2004, I did eXtreme Programming, and did not do all the above that is Scrum and instead did other things, XP practices (pairing, TDD, system test) and how my team executed those practices changed every month/year.

Why did my practices change? Because my teams inspected the WAY we did things and ADAPTED. We talked to and learned from others doing agile and tried out ideas for a sprint. Using the rigors of the experimental process (control/fix everything else but what you want to change, and then measure the results at the end) we decided what new adjustment to keep and what not to keep.

Standards

Should there be a standard way across an organization?
Are you saying that you want a monoculture? Is Scrum itself a monoculture? Maybe, but if each Scrum team is a little or a lot different so I think it's not a monoculture. I think that doing "basic" Scrum (just Scrum) as a standard is a good idea because then everyone from development to the CEO understands the culture enough not to:
Ask team members multitask across different projects
Ask POs to change the team's sprint backlog while they are in mid sprint
Discourage highly collaborative practices like Pair Programming
Discourage differences between Scrum teams
Ignore impediments discovered by teams

We want how we work together standard enough to not break each others' Scrum processes and to support teams' inspection and adaption of their own processes.

Directing an organization without standardizing a monoculture


Standardizing on organizational goals that allow teams to self organize is a good idea. Here are some I've seen in the industry:
burndown chart of some kind, definitions of done,
Automated system tests, automated unit tests, a system to show how many tests are passing/failing in the last hour, collocated teams, a highly visible team task board the team can use throughout the day, current code coverage and sprint by sprint history so we can see the trend.

The one TRUE way to Scrum

When an organization leaves Waterfall for Scrum, people need to be well trained on what is Scrum and asked to do things they are uncomfortable with, maybe even things they can't imagine could work. They need this pressure to get started doing Scrum otherwise, before even their first sprint, they decide to inspect and adapt to something they are comfortable with, Waterfall, out of a sense of comfort rather than out of quantifiable measurements that come out of the Scrum process (Velocity is a big one). So to get a team started, they will need to take a starting Scrum model on faith until they get the idea and see results good or bad. After a few Sprints, I expect to see that the cumulative affects of inspect and adapt to show some changes from their starting Scrum model but to still see the basic Scrum model intact.

If someone says that they have one true way to do Scrum, I'd start walking the other way because that person doesn't understand that Scrum requires teams to inspect and adapt their process to become efficient for their specific situation. If a team isn't inspecting AND adapting, then their Scrum process is broke.

Sunday, February 13, 2011

Hello World, Hello Quickest end to end Implementation

What is the fastest your Agile team can bring something to market? If you don't know, it's time to find out. You might be surprised at the answer. When working with clients who struggle to understand potentially shippable, I found that talking about releasing a Hello World story is a good way to learn how well their development, technology, and QA processes work.

Recently, I worked with a ScrumMaster who said his team would need more than 1 day but less than 2 to build, test, package, deploy, and then system test the installation. This was much better than his first answer: we don't test the package during each sprint, we don't do a Sprint Deno because we can't. Talking about adding a Hello World story is a good way to structure people's thinking about an easy to visualize goal. Then it's easier to talk about what impedes realizing the goal.

It's also a good way for the team to learn how to do all the engineering practices for from one end to the other: acceptance test, tdd, pair, ... And measure the overhead (what impedes them).

Thursday, February 3, 2011

Agile Resource Management and the "Perfect Method"

Managers whose companies are in the agile transition period often have questions about resource management. With Agile, it's quiet different than what they are used to. If we understand why "traditional methods" exist how they are, we'll better understand what activities are no longer relevant for an Agile project.  Here's a look at Agile's Planning Game versus traditional project management and resource allocation.

The Planning Game
The goal of planning is to get the most value for the business/customer for the amount of time spent on the project. To achieve this, we need to get development and business working well together. If the relationship is poor or if there are many layers of middlemen (management, analysts) separating the layers, then the planning outcome will suffer, even the project is considered an Agile project. This is why XP and Scrum both want the customer (or the Product Owner--one person who can make decisions as if she were the costumer) at the planning meetings and interacting with the team as often as possible. Agile methodologies also ask that the team work differently together: cross-functional, small releases, pair programming, production quality code released at the end of each iteration, etc. (See the following for more: http://www.extremeprogramming.org/rules.html)

Traditional Project Management in the Enterprise
Traditional project management evolved into having layers of people between those who can make decisions about requirements and those who are building the software. Among other reasons, this was done as a way to scale work out to hundreds or thousands of people. A number of middleman roles were created and these middlemen worked more or less as a negotiating layer between the business and the development, maintaining records of decisions. This slowed down decision making due to the team or business working through layers analysts/management to communicate with each other, and often using media (documentation, email) that was inferior to face to face communication.
The outcome of having a slow decision and communication process was that people on both ends found other things to do while waiting: business people started another project and generate business specifications; and the development team became managed by a resource manager who found another project to work on. These other projects executed using the same traditional planning style. Because making decisions was slow in this process, following THE PLAN became very important because changing the plan meant more meetings, more decisions, and more waiting. Team members could be on three or four slow moving projects. Resource managers were busy in making sure people's time was as fully allocated. To make their management easy, each project needed to add to THE PLAN how they were keeping each person busy. If a project's PLAN changed, this created change in personal (adding or removing). If estimates were found to be poor, people would do their best to come as close as possible so that THE PLAN wouldn't change, and sometimes a schedule slip was disguised for months. If the business wanted something different done, this would create a change in THE PLAN that everyone wanted to avoid. THE PLAN evolved to measure effort in Perfect Engineering Days (the "Perfect Method"). If a task takes 11 Engineering days, and you have 5 Engineers, then it will finished in about 2.5 days multiplied by some overhead constant to represent meetings, email, and communication. So those 11 days are "perfect engineering days."

Agile and the Planning Game in the EnterpriseThe biggest reason to move to Agile methodologies is that they make business sense. Time to market is an important measure of a company's ability to bring new products to market. If your product is up for sale before anyone else has a similar product, you have a huge advantage in being the only choice. If your 2nd generation product is out for sale while the competitors only have their first generation, you have a captive marketplace that can only buy from you. Some members of the market will wait for their favorite vendor, but they won't wait forever.

An Agile team team is set of people who work on one project because for a long time, we knew that multi-tasking over multiple projects created "wait states." Wait states occur within the project and wait states across all other projects that the engineer worked on at the same time. For example, engineer A on project Z waited for something from engineer B, but B worked on his other project V because his manager wants to see more progress because V is becoming the "long line" in a multi-project release. After engineer A spent time discovering the wait state, she found something else to do: re-remembering what her other project, Q, was doing, setting up a build environment, and paying other Costs of Task Switching. Everyone knows that multi-tasking adds to overhead, it's only a matter of debate about how much overhead, and finding an alternative. The trouble is that multi-tasking breeds more multi-tasking, as you saw with engineer A.

The Agile Alternative
Part of Agile's better execution speed is realized by breaking away from making plans that fixed business requirements, features, and individual resources together. Everyone on the team is full time on one project until it releases, and let the team manage balancing the work load. Agile's productivity measure, Velocity, is a team wide metric. Velocity measures team productivity and is updated each iteration. Perfect Planning method only estimates cost of effort of an individual to do the work during a perfect day. Velocity will show the impact of process changes. Perfect planning will not as it's only measuring the cost which will need to be updated if the team discovers they need to "double their estimates." Velocity measures results of execution. Perfect Planning measures time for a work item.

Each iteration we have a Planning Meeting where we play the Planning Game
[source: http://www.c2.com/cgi/wiki?PlanningGame] where the team's latest Velocity and their estimates of the backlog of stories/requirements are used to give the business the most up-to-date data on what stories can/cannot be done. Re-planning happens each iteration based on this information (stories are adjusted, people may be added/removed from the team). We expect to re-plan each iteration, where Traditional project management expects THE PLAN to never change (which is a false assumption since it always changes). The team, uses Velocity to guide how much work to pull into the forthcoming iteration. Perfect Engineering Days aren't used because it brings along with it a stipulation that only one person is working on each task (and over simplified the ability to divide and conquer). The team members may use the practice of Pair Programming in order to have fully reviewed code, better designed, and a fully cross functional team where everyone understands what the software is doing. (Note: You could choose to use Perfect Paired Engineering Days http://xprogramming.com/Practices/PracIterations.html. But there are better systems out there which are a better fit for how human brains work: http://www.renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf ) [*]

What's a manager in a transitional organization to do?
If people demand that you express your team's allocation by engineering days so they can add it into a planning tool, then find a way to make them happy without having "resource allocation reporting" affecting your team's agile process (Pair Programming, using Planning Poker with a numbering system rather than "Perfect Method", cross functional team members, ...). For example, if you have six people on your team, and based on the team's most recent Velocity, they are going to finish the most up-to-date version of the backlog in two months, then you have twelve engineering months. Find a way to fill out the report to make the organization happy. Eventually, and by educating your organization, you'll be able to drop this "Perfect Method" Wrapper.

"Perfect Method" Wrapper Patterns
Since many companies are in similar straits when transitioning from a traditional organization to an Agile organization, many project managers turned ScrumMasters or XP Coaches are faced with this problem over and over. Wouldn't it be nice to have a list of solutions that people have done to solve this impediment? That's where you, dear reader, come in. If you're in a transitioning organization or have just finished doing a transformation, use the comments section (moderation is turned off, so go for it) beneath this blog to describe what you did or going to try to keep your team agile when your department wants you to report on your use of human resources via perfect engineering days.


[*] I'm more proscriptive than James Grenning in that I ask teams to resist adding more numbers into their numbering system. If you're using the Fibonacci system (1 2 3 5 8 13...), stick to it! Otherwise the team'll waste time deciding between 5 and 6 rather than quickly finishing planning by deciding between 5 or 8. I'm even more extreme in that I recommend a geometric series instead (1 2 4 8 16 32) which has even bigger gaps. Having gaps are important because humans are better at making quick decisions over these gaps between numbers rather than a long debate with a liner system where there isn't much difference.