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.