Agile methods are often described as “common sense”. For this reason Ken Schwaber refuses being titled the Co-Creator of Scrum. Several software development practitioners such as Ivar Jacobson, Grady Booch, and James Rumbaugh all contributed to the set of principles that today form the Scrum framework.

However, having Scrum, XP, or any other method classified as common sense leaves a lot of room for interpretation by the individuals applying them. Thus, iteration planning efforts sometimes end up being superficial, not entirely committed to the system actors’ real goals. As a practical consequence, user stories are found reduced to single sentences hanging on the white-board.

It is clear that User Stories are not Use Cases or Requirement Statements, as detailed by Mike Cohn, and highlighted as follows. Firstly, use cases are generally written as the result of a long analysis, whereas user stories are written as notes that will be used to initiate further analysis conversations. Secondly, requirement statements make costs visible only when all of them have been formally written in a lengthy document, whereas with user stories a complexity estimate is associated with each story immediately. Costs are then easily calculated by taking into account the velocity of the team.

Nonetheless, developers should not underestimate the complexity inherent in each story, and complementary theory can be found on this topic. Ron Jeffries breaks down the stories into three aspects: Card, Conversation, and Confirmation.

Firstly, the card does not detail the story in depth, but successfully identifies it. Typically, team members and product owners adhere to the following template, popularized by Mike Cohn: “As an <actor>, I want to <action>, so that <achievement>”. Although advantages derived from using this template have been listed, other agile evangelists have proposed enhancements. Elizabeth Keogh, for instance, came up with a new user story format that better emphasizes business value. One way or the other, templating has been the common approach, and teams should adopt one that will fit in smoothly within their environment.

Secondly, conversation is the activity that communicates the requirement from customers to developers during the product and sprint planning. At this stage, details such as dependencies and barriers are mapped out. As depicted by Jeffries, the conversation is largely verbal, but is often supplemented with documents. It is important to bear in mind that good communication is a key success factor in any software development project, and none of the artifacts produced throughout the process may substitute that.

Finally, stories are verified through confirmation or, more specifically, acceptance testing. All criteria taking into consideration ought to be defined during planning phases as well.

Although the theory presented above brings some structure to the loose perception of user stories, the writing itself remains vague. So William Wake advocates that agile practitioners should INVEST in good stories and SMART tasks. Despite not being a particular fan of forced acronyms, I have to admit that some guideline will be welcome here.

Briefly, characteristics that form a good story description are the following:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

.
Hence, a story should be independent from others, negotiable between customers and programmers, valuable to customers, estimable in terms of complexity, small for the sake of understandability, and testable on account of readiness confirmation. Further studies suggest that “Small” should be replaced with “Sized appropriately”, as the bottom of the product backlog may contain items that are not fully understandable by the team yet, also known as Epics.

Tasks, in their turn, should be:

• Specific
• Measurable
• Achievable
• Relevant
• Time-boxed

.
So a task needs to be specific by addressing one particular point, measurable in order to be tested against the definition of done, achievable by the task owner, relevant to the story at hand, and time-boxed. This latter characteristic should not be perceived as a formal estimation in hours or days though, as it does not work. The raw material in Software Engineering is the developer’s own intellect, and nobody would be able to estimate its maturation time. The same applies to activities such as painting or novel writing. Civil Engineering, on the other hand, benefits from using raw materials that allow for accurate calculations, such as concrete and iron.

As a final note, during the planning, instead of defining longer iterations and allowing for bigger stories, you might be interested in giving the following set of constraints a try. SWAT has successfully built some of its software by adhering to them. Manageability goes through the roof!

• 5-day sprints
• 5-point stories, or less
• 2-developer teams, up to 4

.
In conclusion, a better organized agile planning is more likely to drive the team towards the goals identified by project stakeholders. Theories and guidelines have been proposed, and I suggest bringing these concepts to the table when starting a new agile project.

For those not familiar with Scrum, let me summarise the key principles quickly:

1. A project team is setup usually consisting of between 5 and 9 resources.
2. The resources within the team have the set of skills needed to develop products.
3. There are defined roles within this setup, namely

• The Product Owner: Manages a list of product features that require development. These features are prioritized by the Product Owner.
• The Scrum Master: Ensures that the processes are followed and helps the team deliver the product features by removing any impediments that prevent them from delivering.
• The Team: Self organises around the product features and collectively work together to deliver these product features.

I’m simplifying the roles here of course – there are further responsibilities that are played by each role, but this is the essence.

4. The team produces working demonstrations of the product features at regular intervals (typically every two weeks).
5. These working demonstrations are visible to the business, allowing the business to get a view on where the product is going and whether it needs refinement or a complete change in direction.
6. The refinements or improvements are then fed back into the team, prioritised by the Product owner and driven through to demonstration once again.

The framework is agile in nature. Problems are quick to identify, and quick to change. Traditional project management methodologies would allow a project to proceed down a long and drawn-out development path and if the up-front analysis had not been 100% accurate, or if external factors had required a change to the project during development, this would be very difficult to accommodate. The Scrum process by contrast makes sense – it is a simple, logical way of delivering projects and caters for changing requirements.

That said, the question of how to setup the Scrum team and environment remains. As a new team, we are facing these questions and trying to figure out the best path to creating the esteemed “High Performance Team“. There are two schools of thought here. Let me deal with the first.
As competent and experienced team members, there is a sense of “doing things right, from the start”. This includes everything from ordering the right development hardware, deciding on what software is appropriate, defining the practices and principles the team is going to follow, which languages are best suited for the projects that need to be developed, and what the collaboration environments need to look like. All good stuff, and completely necessary. The planning also includes discussion and decisions around how to test the code that is developed, how it is documented, how much of this is automated versus manual, which tools are best suited for testing, how new issues get logged and fed back into the team, and how much test coverage is considered acceptable. Again, all good stuff, and all appropriate to the work that is being done within the team. It is also a good idea to get the overall context of the project defined up front so that broad architecture decisions can be made. Where the team needs to be careful however, and we are all sometimes guilty of this, is when it comes to over-engineering a solution up-front. Chances are that this picture is changing, or will eventually change. Nothing wrong with good architecture up-front, but trying to understand too much detail too soon is probably wasted effort.

Lets take a look at the second school of though for a moment. The principles of Scrum and Agile development methodologies and practices suggest that the value lies in delivering small, incremental features, regularly. Mistakes and changes to project scope are inevitable and it is the ability of the team to correct these mistakes, and accept the changes in scope that makes them “High Performance Teams”. Through continuous feedback and team “retrospectives”, the gaps get filled, and the holes get plugged. The team continues to improve as a result and the delivery continues to speed up – well, from the initial stages anyway. Its a situation in which the team adapts the principles of Agile software development to suit their unique environment, the individual strengths and weaknesses and their team characters.

The point that I am trying to make here, is that there are two ways to try and achieve the “High Performance Team”. There is the “Lets build the 6-foot armour-plated robot with Augmented Reality vision”, or, the “Lets build the stick man and determine what he needs next” approach. There is a fine line between setting up a team that does everything right from the start, and a team that is setup to learn how to do what is right for them.

I was recently made aware of an agile development team based in the UK that has been together for the past 60 months. They deliver code weekly, have a number of visible metrics for how many bugs are in their system and how quickly they are resolved, what the velocity (capacity for delivery) of the team is, converted into monetary value, and a number of other “reporting” metrics. Incredibly useful information, and a sign that they are a “High Performance Team”, but I wonder how much of that was setup from the start, and how much of it “evolved” as the team progressed through their 60 months of development together?

To take the analogy used above, whilst it is important to have a team vision in place and to follow best practices where ever possible, I firmly believe that it is best to create the stick-man from day one, and get him running in an agreed direction, rather than spend too much time thinking and planning the 6-foot robot that potentially is only capable of taking a few steps at a time, and hopefully, in the right direction.

That being said, our team is in a good place. We are positioned nicely and are moving forward as a unit. Hopefully the discussions that our team have had, and the conclusions drawn here, can help you position and setup your own team.

Origin:

The term Scrum comes from a study by Hirotaka Takeuchi and Ikujiro Nonaka in 1986, which was published in the Harvard Business Review. In this paper (The New New Product Development Game) they described a holistic approach in which the development phases overlap and where project teams are made up of small cross-functional teams. They compared these high performing teams that work together towards a common goal, to the Scrum formation in rugby.

The first software development Scrum was created at Easel Corporation in 1993 by Jeff Sutherland, who used their study as the basis for team formation and adopted Scrum as the name of the process as a whole. Jeff introduced Scrum Ken Schwaber in 1995, who then formalized the process for the worldwide software industry in the first published paper on Scrum at OOPSLA 1995.

Definition:

Various definitions of Scrum exist, but the following two defines it the best.

[ScrumPapers - Nuts, Bolts, and Origins of an Agile Process by Jeff Sutherland] Scrum is a simple framework used to organize teams and get work done more productively with higher quality. It allows teams to choose the amount of work to be done and decide how best to do it, thereby providing a more enjoyable and productive working environment. Scrum focuses on prioritizing work based on business value, improving the usefulness of what is delivered, and increasing revenue, particularly early revenue. Designed to adapt to changing requirements during the development process at short, regular intervals, Scrum allows teams to prioritize customer requirements and adapt the work product in real time to customer needs. By doing this, Scrum provides what the customer wants at the time of delivery (improving customer satisfaction) while eliminating waste (work that is not highly valued by the customer).

Scrum is a simple “inspect and adapt” framework that has three roles, three ceremonies, and three artifacts designed to deliver working software in Sprints, usually 30-day iterations.

• Roles: Product Owner, ScrumMaster, Team.

• Ceremonies: Sprint Planning, Sprint Review, and Daily Scrum Meeting

• Artifacts: Product Backlog, Sprint Backlog, and Burndown Chart

[An Overview of Scrum – Mike Cohn] Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.