Does size matter?
 

Estimations in scrum/agile environments often gets tangled in conversations about how big of an effort that is required. The questions that are often asked are “how much of effort?”, “how long/sprints it will take?”, “Is it too complex?”

Scrum provides a model where these questions are easily compressed to a simple thing called story points. Story points is a number denoting the complexity/effort/time taken by the team to solve a problem (story). Story points are often a number of Fibonacci series. (1, 2, 3, 5, 8, 13 …). The scrum team defines what it means by a 1 pointer story. For example one of our teams defined a 1 pointer as “one line of code change”.  Also as the number of unknowns in a story is high, team provide higher story points for the story.

However the size of the story points is not important because

  • Story point size is specific to the team and can not be used to compare teams. A story could be sized differently by different teams based on the understanding of the product, technology and experience.
  • When a management provides a commitment on a given epic/release to the customer, the delivery timeline is often determined by the velocity and not by individual story sizes.
  • Story points are a relative sizing of the stories and not a exact reflection of complexity/effort
  • Bigger story points does not mean higher customer value. A refactoring story or a story of lower business impact could be sized bigger.
  • Story points are time bound. The team could size the story differently depending on their understanding, as their knowledge/understanding changes their story sizes also change. This is one of the reasons some teams re-look at the story sizes during sprint planning although they are sized.

Please let us know your thoughts, using story points? does size matter?

Agile Manifesto and Core Principles
 

The agile manifesto says

Individuals and interactions over processes and tools

When I first time read this statement, I was little puzzled in terms of identifying the focus or intention behind this starting point. I had following question in my mind

  • Should we give little/no preference to tools or processes. Or if we do, to what extent.
  • Why is communication is so important? Why can’t we get it done utilizing tools so called ‘Agile Tools’?
  • What does it mean by individuals?

The whole world make use of processes and tools. The tools like JIRA has gotten lots of popularity.  At a time you feel that things can just go right even though there are distributed teams or people don’t interact much. The real truth is agile focus on people, communication and internal interaction.  In order to understand the real intention just replace the word “over” with “before” and it would make better sense. One cannot replace processes and tools completely while the communication gets more priority.  The collaboration, interaction and internal trust makes self organizing teams. The lack of self organizing teams result in ‘Handicapped Agile’.

Working software over comprehensive documentation

The comparison here is with waterfall or traditional development methodology where the customer requirements are documented start to end with huge sets of artifacts. I have personally seen team spending more time in documentation over building software. It is virtually impossible to document every piece of requirement in the beginning for most projects. Moreover the sign off from customer is just a formality as customer is dreaming of working piece over what is there in requirements. The elaboration of requirements itself is complicated and further there are so many unknowns.  The Agile believes in incremental development  and continuous delivery of working software to ensure the work is being done with respect to customer expectations.

It is good idea to have limited documentations while this statement every agile developer has taken it so seriously and developed a myth there should not be any documentation to be created at all.   Having product document, user manual or specifying common issues etc. would help project to run smoother.
Customer collaboration over contract negotiation

There is a common myth what I have seen in most of the projects I have gotten into that is “We don’t need a contract with customer and we would do it as we move forward with development”. This is one of the most misunderstood statement among developers and folks getting on to Agile. We obviously need contract and while the customer involvement gets more priority. Let me give you an example to understand this better.

Assume that you want to build a connector to connect to your IAM product to customer application to perform provisioning. The product roadmap and release planning is over post feasibility. As per release planning we have divided the work into number of sprints say 2 weeks 24 sprints. At this point as we constantly showing the working product to customer, the changes are welcome. The scope creep can be managed in this case is either by removing something from sprint of similar size which is not being worked up or adding that item in future sprints (not the work in progress). This might result in adding one or two sprints to overall 24 week sprint (Possibly we can reduce that while this kind of chances are fat)

Adding one or two sprints or probably more won’t disturb customer as at the end he would have a solid product and moreover the changes are proposed by customer which could be because market dynamics have changes, customer has missed the requirements or could be anything else.
Responding to change over following a plan

The successful product matters over complicated plans. Agile is extremely adaptable and typically go with release schedules while each release comprises of one or more sprints. The water fall model simply follow the plan and any change in requirement is very tough to include and further adds lots of cost to it. The flexibility of managing scope creep makes Agile superior. The focus is always respond to change. I have personally seen 6 weeks sprints have changed to 20+ weeks while customer was really happy as he has gotten what he wanted.

Here you have principles behind Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

There are number of reasons

  • Customer gets confidence by constantly getting the working software.
  • The early time to market adds lots of value.
  • The market dynamics helps to make changes to products.
  • More than 60%+ software projects are scrapped before they are complete. This percentage can be reduced and further if you product is not good enough you got to know well in advance and you can take a call whether you want to continue or stop it.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The changes are always welcome. The customer gets what he wants and it would not hurt developer or company building the software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

You know where you stand and the same is with respect to customer. This is probably the biggest benefit of agile.

Business people and developers must work together daily throughout the project.

The biggest reason for most of the projects failure is the team working in isolation with no clue whether they are on track. Working closely with customer constantly not only gives confidence to customer while at the same time benefits to team to be aligned well with customer with respect to their requirements.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

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

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.