Agile fAq

In agile development there is no right or wrong. Both Use cases and user stories are offshoots of agile methodologies. User stories have a XP and Scrum backgroung and
use cases dont.

Use cases tend to be a written level contract ( sometimes ) too detailed, sometimes not. There are typically few main sections to a use case. A use case Summary, actors, main scenario, alternate scenarios

There is no one to one mapping of a use case to a user story. Summary is like a story defintion. A use case can break into many small stories.

The main scenario in itself is a story with the actual line items in a main scenario becoming the acceptance criteria. The alternate scenarios become either thier own stories or in some cases simply acceptance criteria.

Both use cases and user stories are as good as the effort put in to write them. Both can turn fairly quickly to a rather mundane and useless document.

Here is an example of a use case broken into stories and acceptance criteria.

USE CASE FORMAT

Use Case Number -1

Actor - Bank customer
Summary - Customer withdraws dollars from his / her bank account.

Main Scenario

1. Customer inserts debit card into an ATM machine
2. ATM machine asks for a four digit pin
3. Customer enters the pin
4. ATM machine verifies the pin and it is valid
5. Customer enters the amount
6. Since there is enough bank balance, ATM dispenses the amount and debits the account.
7. ATM gives the card back to the customer
8. Use case ends.

Alternate scenario

4a) Four digit pin is invalid, ATM machine gives an error and asks the user to retry.
6a) There is not enough balance is the account. ATM machine gives a corresponding message

USER STORY FORMAT

As a customer i want to withdraw some dollars from the shop so that I can buy things i like.

Acceptance Criteria.

1) The customer should be able to enter a pin number. IF the pin number is vali the system should prompt the user for a dollar amount to withdraw.If the pin numer is invalid or there is not enough balance the sytem should show a error message.
2) If there is enough balance the system should dispense the cash and debit the account.

As noticed in the example a user story is converstional and conveys the same thing a use case does. It is a small card , with a conversation that is the acceptance criteia.

In case you need to use use cases use the use case as a start and break them down to stories. If done well, stories should be enough detail for the team to develop the system.

This slide deck from Crisp is a great list to some smells you should watch for when implementing agile practices.

If the team is really not empowered to get the job done, that will bring the system down. You know that the team is not being empowered when each team member does not take responsibility or stays shy of taking decisions. If they always look up to the scrum master or dev lead. If a chief architect walks in a spoils thier plan and no one in the team is empowered to speak back. Telling teams and letting them know that thier destiny ( by which i mean ), how they want to work in the project is completely up to them. Team should get a lot of help in the beginning from experienced coaches. This saves a lot of time wasted later.

TEAMS MAKE OR BREAK AGILE COMPANIES

“Secrets of Agile Teamwork” by Esther Derby and Diana Larsen.

Leadership Role Responsibility of Role

1. Instructor Answers Questions and Supplies Data
2. Follower Provides Support and Encouragement
3. Coordinator Links and Integrates Data
4. Peacemaker Works for Harmony and Compromise
5. Gatekeeper Maintains Working Agreements and Discipline
6. Monitor Makes sure relationships are working
7. Pioneer Asks questions and Seeks Data
8. Influencer Initiates working agreements and team culture
9. Commentator Explains and Analyzes Data
10. Promoter Helps and Encourages Quiet Members
11. Critic Evaluates and Analyzes Relevant Data
12. Reviewer Periodically Checks and Corrects
13. Devil’s Advocate Deliberately looks for alternative and oppositional views

This paper focuses on agile productivity. “Individuals and interactions over processes and
tools”, means an average developer is required to interact with others for quite a while
in their day. This is very different from traditional development where face to face
interaction is not that much. Added on to this high interaction in agile teams, is the
interference of meetings, lunch breaks, stand ups (In Scrum), and other technical
challenges like chats and emails.http://agilefaq.files.wordpress.com/2008/03/agileproductivity.pdf

This is a recent email chain that talks about this issue. Very interesting. Thanks to all responders . Posting here for benefit of the larger group.

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

http://www.scrumalliance.org/articles/14-technical-debt-and-design-death

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
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 feeling 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 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.

1. Come prepared to answer three questions and be in time - What did I do yesterday?, What Am I doing today?, Any Impediments?
2. This is not a status report. This is your time to share thoughts with the team, so that they know where you ( or your pair) are and can act accordingly. This is also your time to ask for help and to offer help when asked.
3. Address your team in a loud voice, and don’t report to the project manager
4. All pigs -Stand in a circle around visible indicators like task board, impediment chart and a phone for those dialing in. All Chickens - Stay away and be quiet. After the stand up you can speak too.
5. Keep it short. No standup should go more than 15 minutes.
6. Bring at least one impediment to the stand up.
7. Pick a pairing partner.
8. Make sure the product owner is always there.
9. If this is a distributed team do stand ups separately in the two places and then use another standup to report cross team activities later in the day.
10. Do this first thing in the morning and may be last thing in the day with distributed teams.

This is a standup, so don’t sit.

Customers Measure Success on one of more of these criterias

At a high level:

• Is the project in production?
• Is the product producing revenue?
• How long since development I could get the product to generate revenue?
  • Sometime agile products iterate for a very long time and when finally released end up looking like a waterfall effort.
• How much did i spend in developing a story point or a use case?
• What was planned and how much did I end up spending?
• Is the product in a decent shaped to take it to market?
• How often has the team delivered value?
  • One of the key aspects of agile development is to pick stories that provide value to the business from very early on. It is critical for the success of agile projects that there is a balance of stories from just a feature that enhances a functionality to one that can generate revenue.
• Number of level one of two defects?
• Are all the stake holders satisfied?
• What are the customers saying?
• Have we increased the customer response time?

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.

Agile does not mean paper napkin architecture. On a system that is large scale the team needs to be thinking about architecture at all times. This does not necessarily translate to lots of upfront architecture.

But key architectural / design issues should be verified using spikes or conceptually to some extent, to to address key tenets of architecture like layering, tight coupling, scalability, testablity etc.

Agile teams esp XP teams consisting of senior developers can pull off with Just in time architecture. But in most cases the team consists of a mix of developers and to expect every member to contribute to the evolution of architecture is a challenging task. 

An architecture vision and some detailed archicture analysis ( may be for a sprint or two) is good  for the overall health of the system.

http://www.agilejournal.com/articles/articles/scaling-agile-development-via-architecture.html

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.

By 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!

Story point is a random measure used by Scrum teams. This is used to measure the effort required to implement a story.

In simple terms its a number that tells the team how hard the story is.

In most cases a story point range is

1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large

It is a relative term and does not directly co relate to actual hours . Since story points have no relevance to actual hours, it makes it easy for scrum teams to think abstract about the effort required to complete a story.

This also creates a lot of confusion as most scrum masters who come from a PMP background relate this immediately to hours.

Story points do give some indication of how much time time was spent in a sprint.

Example lets say at the end of a 10 day sprint a team of 4 covers 40 story points.

10 days = 10 * 8 working hours = 80 hours. = 320 total hours as there are 4 developers.

That equated to 160 pairing hours.

160 divided by 40 =  4 hours pair hours per story point.

 = Number of total story points / One iteration

Velocity is a measurement of how much the team gets done in an iteration ( called as Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is planned.

In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

Examples are 1, 2, 4, 8 , 16

5, 10 15 and so on.

A story depending on its complexity is given certain story points. So if the team does 6 stories that are 8 story points that iteration , the teams velocity is 48 story points.

KISS in Agile stands for Keep it simple Stupid

This applies to everything from planning, to design to development.

Do the simplest thing possible.

Don’t make it up.

Keep it simple

If a team consists of many members, pairs tend to get friendly. Like a courtship. If a pair starts to get along very well, then they prefer to only pick each other.

This leads to specialities and can cause specialization. Example John and Peter always work on the database layer code and get it done really well . Hence the team starts giving all the database tasks to them starting to cause bottlenecks. Everyone who needs database scripts are now waiting for John and peter to get it done.

Promiscuous Pairing is way to avoid this.

Pairs change on a daily basis. Tends to keep the knowledge well spread across the team

A random pair draw at the daily meeting is a way to pick these pairs.

This could cause other effects as developers tend to like some and not like others . Promiscuous Pairing forces the member to get over thier issues and can cause unforseen tensions and a drop in efficiency.

Pun intented here.
If you do a lot of pair programming think again
““

here are some reasons why you should use your own keyboard at all times
1) Your pair has a virus ( real kind ) and is sneezing all over the keyboard
2) Your pair had a flu and is recovering from it.
3) Your pair is holding fries in one hand as he./she types and uses the keyboard with the same hand . Umm french fried keyboard.
4) You turn your pairs keyboard on the side and see all the food particles and dandruff fall.
5) Your pair went to the bathroom * enough said
If i have convinced you enough carry your own keyboard for pairing sessions and use purell when in doubt

This applies to the Scrum management process.

This is a document that basically says what needs to happen for the sprint ( iteration ) to be called Done. There are at least three types of Definitions of done.

Story Definition of done

What must happen for the story to be marked as complete.

An example Story definition of done would look like this.

1. All story should have automated acceptance test.
2. The story should have working code supported by unit test that provide around 60 - 70 percent coverage.
3. The story should have well defined acceptance criteria.
4. The code must have been written as a pair or should be code reviewed.
5. Code must be completely checked in to the source control system and the build should pass with all the automated tests running.
6. The product owner must accept the story.

Sprint Definition of done:

1. Product owner should have defined a sprint goal.
2. All stories completed for the spring must be accepted by the product owner
3. All the automated acceptance tests should be running for the stories in the sprint.
4. All code should have been pair progrmmed or must have gone thorough a code review process.
5. If there is a database involved, the database scripts must have been automated and tested.

Release Definition of done

1. Product is deployed to the test box and makes it to staging
2. Product has a formal release date.
3. There are deployment documents for the release
4. Training manuals are available for users.
5. All stories for the release are completed and accepted.
6. The release does not have any level one bugs.

1. If one person in staring at the monitor while the other keeps typing for more than 15 minutes.
2. When a pair starts to become a mini gang. It two members get along well and start pairing they do well, bringing the other pairs down.
3. When pairs are stuck in the same task for ever and start doing other things during thier time
4. Its easy for the pair to lose focus just as one person, if they dont know the ettiquettes of pair programming
5. If one of the pair members is forced to pair.

An XP practice where two programmers work alongside each other, trying to get a task accomplished. Two minds at one problem.

What does this bring about:

 1) It brings up productivity if the pair knows what it is upto. A chatty pair can cause more damage to the project than getting done

2 ) It keeps each person honest. If you dont know something its apparent in the fifth minute.

3) It helps keep the quality of the code. Since the pair is helping code.

4) This is where design happens.

Intent

An Interesting demonstration of democracy that Agile teams often do in order to come to a consensus.

How is this done:

When conclusions have to be done the team is asked to do a fist of five. All the team members put out thier fingers ( five ) . They can show from 1 to five fingers as shown above

What does this mean

1 means you dont agree,

3 means you are not sure but you will go with the team

5 means you strongly agree

Even if one person is below 3 , the decision does not go through. A discussion / debate happens . If you can convince a person less than 3 to come up to a 3, then the decision goes through

Does this work

Not always. If done too much it loses its context. If done once in a few months it holds value.