Problem solving techniques in team

Questions to be answered are

1. What can we do togeather to solve this problem

2.In what ways might solve this problem.

Some of the problem solving techniques

a. Agree to partner and work as a team on solution.

b.Switch to better way of communicating a problem

c.Work one problem at a time.

d.Understand the problem

e.Find solutions togeather

f.Develop ideas for possible solutions

1.Reserve judgement

2.Strive for quantity

3.Free wheel

4.Look for combination

g.Evaluate ideas carefully

h.Plan for success

Glossary of Scrum Terms

Glossary of Scrum Terms
• Burndown Charts
• Daily Scrum Meeting
• Impediments
• Product Backlog
• Product Backlog Item
• Product Backlog Item Effort
• Product Burndown Chart
• Product Owner Role
• Release
• Release Burndown Chart
• Scrum Roles
• ScrumMaster Role
• Sprint
• Sprint Backlog
• Sprint Burndown Chart
• Sprint Goals
• Sprint Planning Meeting
• Sprint Retrospective Meeting
• Sprint Task
• Team
• Team Member
• Velocity
Burndown Charts
Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.
The Scrum books define a sprint burndown chart as a place to see daily progress, and a product burndown chart as where to show monthly (per sprint) progress.
Daily Scrum Meeting
A fifteen-minute daily meeting for each team member to answer three questions:
1. "What have I done since the last Scrum meeting? (i.e. yesterday)"
2. "What will I do before the next Scrum meeting? (i.e. today)"
3. "What prevents me from performing my work as efficiently as possible?"
The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints.
The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
Impediments
Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily Scrum meeting. The ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.
Product Backlog
The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog.
During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.
Product Backlog Item
In Scrum, a product backlog item ("PBI", "backlog item", or "item") is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks.
See also backlog effort estimation unit.
Product Backlog Item Effort
Some Scrum practitioners estimate the effort of product backlog items in ideal engineering days, but many people prefer less concrete-sounding backlog effort estimation units. Alternative units might include story points, function points, or "t-shirt sizes" (1 for small, 2 for medium, etc.). The advantage of vaguer units is they're explicit about the distinction that product backlog item effort estimates are not estimates of duration. Also, estimates at this level are rough guesses that should never be confused with actual working hours.
Note that sprint tasks are distinct from product backlog items and task effort remaining is always estimated in hours.
Product Burndown Chart
In Scrum, the product burndown chart is a "big picture" view of a project's progress. It shows how much work was left to do at the beginning of each sprint. The scope of this chart spans releases; however, a release burndown chart is limited to a single release.
The following example illustrates a product burndown chart, for an example (ACME ) product:

For more on product and release burndown charts, please see:
http://www.mountaingoatsoftware.com/release_burndown
Product Owner Role
In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions.
This person must be available to the team at any time, but especially during the sprint planning meeting and the sprint review meeting.
Challenges of being a product owner:
1. Resisting the temptation to "manage" the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself.
2. Resisting the temptation to add more important work after a Sprint is already in progress.
3. Being willing to make hard choices during the sprint planning meeting.
4. Balancing the interests of competing stakeholders.
Release
The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it.
"The product is released to customer or marketplace obligations. The release balances functionality, cost, and quality requirements against date commitments." (Schwaber/Beedle, Agile Software Development with Scrum, p. 80).
Release Burndown Chart
In Scrum, the release burndown chart is a "big picture" view of a release's progress. It shows how much work was left to do at the beginning of each sprint comprising a single release. The scope of this chart is a single release; however, a product burndown chart spans all releases.
For more on product and release burndown charts, please see:
http://www.mountaingoatsoftware.com/release_burndown
Scrum Roles
There are three essential roles in any Scrum project:
• Product Owner
• ScrumMaster
• Team
ScrumMaster Role
The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:
• Remove the barriers between the development and the product owner so that the product owner directly drives development.
• Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
• Improve the lives of the development team by facilitating creativity and empowerment.
• Improve the productivity of the development team in any way possible.
• Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
• Keep information about the team's progress up to date and visible to all parties.
Source: Agile Project Management with Scrum, Ken Schwaber
Sprint
An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of product must be produced each sprint.
The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the sprint (one per day). At the end of the sprint we have a sprint review meeting, followed by a sprint retrospective meeting.
During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep.
Out of practical necessity, some teams choose to bend this rule by declaring some team members 80 percent available at the outset so they still have some cycles left for "Priority One" bugs and emergencies. But this is a slippery slope and should be avoided whenever possible.
Sprint Backlog
Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.
Sprint Burndown Chart
A sprint burndown chart (or "sprint burndown graph") depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the product backlog items that achieve the goals of the sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours).
To motivate the team, the sprint burndown chart should be displayed prominently. It also acts as an effective information radiator . A manual alternative to this is a physical task board .
Ideally the chart burns down to zero by the end of the sprint. If the team members are reporting their remaining task hours realistically, the line should bump up and down chaotically. The profile shown below is typical, and demonstrates why the "percentage done" concept of traditional project management breaks down. Assuming we started measuring on July 26, what "percentage done" were we on July 28?

Sprint Goals
Sprint goals are the result of a negotiation between the product owner and the development team.
Meaningful goals are specific and measurable. Instead of "Improve scalability" try "Handle five times as many users as version 0.8."
Scrum focuses on goals that result in demonstrable product. The product owner is entitled to expect demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.
Have your team commit to goals that anyone will be able to see are met (or not met) at the end of the sprint. At sprint review meetings, the sprint demonstration is conducted after which the team asks the product owner whether (s)he feels the goals were met.
While some specific product backlog items may not be done at the end of a sprint, it should be very unusual for a team not to meet its sprint goals. Scrum requires the team to notify the product owner as soon as it becomes aware it will not meet its goals.
Sprint Planning Meeting
The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint.
oThe product wwner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the uncommitted backlog to the sprint. Often new backlog items are defined during the meeting. This portion of the sprint planning meeting is time-boxed to four hours.
Typically the team will then excuse the product owner from the room and break the backlog Items down into tasks. The product wwner is expected to be on call during this phase (previously called the sprint definition meeting) for renegotiation or to answer questions that affect the time estimates. This portion of the sprint planning meeting is time-boxed to four hours. Sometimes teams insert placeholder tasks (with rough estimates) for the product backlog items they don't expect to start working until later in the sprint.
Sprint Retrospective Meeting
The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting.
The sprint retrospective should be time-boxed to three hours.
Kelley Louie (Certified Scrum Practitioner) writes: "The sprint retrospective meeting is an integral part of the inspect and adapt process. Otherwise, the team will never be able to improve their overall output and not focus on the overall team performance. The ScrumMaster must pay attention to this meeting and work towards resolving the impediments that may be slowing down the team."
Consider using a Scrum scoreboard during the retrospective.
Sprint Task
In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart. Tasks are contained by backlog items.
Scrum literature encourages splitting a task into several if the estimate exceeds twelve hours.
Team
A team (or "Scrum team") is optimally comprised of seven plus or minus two people.
For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called "cross-functional project teams". Agile practices also encourage cross-functional team members.
During a sprint, the team self-organizes to meet the sprint goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The ScrumMaster acts as a guardian to ensure that the team is insulated from the product owner.
Scrum also advocates putting the entire team in one team room.
Team Member
In Scrum parlance, a team member is defined as anyone working on sprint tasks toward the sprint goal.
Velocity
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
Once established, velocity can be used to plan projects and forecast release and product completion dates.
How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates.



Source from Scrumalliance

Extreme Programing Document - terms

Scope and Objective
The purpose of this document is to provide a development methodology based on Ex-treme Programming (XP).

Prerequisites
Developers should be familiar with software development lifecycles and methodologies, Extreme Programming in particular. Customers should be familiar enough with the func-tional domain to be able to clearly describe the behavior of the system being developed.

Definitions
Class Diagram A graphical representation of the structure of a system or subsystem (as described in the UML).
Collaboration Diagram A graphical representation of the relationships between system components that interact to perform a task (as de-scribed in the UML). A system component may participate in more than one collaborations.
Customers Users or Representatives (such as product managers or business analysts).
Deployment Installation of software into a particular environment (such as build, test, or production).
Entity-Relationship Diagram A graphical representation of a database schema.
Ideal Hours An estimate of development effort under perfect conditions.
Iteration A time period of one to four weeks containing a subset of the stories in the release.
Metaphor A short description of the vision of the product and each re-lease, used to develop a shared understanding among the members of the Project Team.
Pattern A reusable design element. In the UML, a pattern is repre-sented as a parameterized collaboration.
Project Team Developers and Customers, may also include QA person-nel.
Promotion A deployment from one environment to another (such as from build to test).
Spike A research-oriented story estimated on the basis of time needed to find a solution. Additional time may be needed for implementation.
Sponsor The person providing resources for the project.
Story A functional story describes the user experience. A techni-cal story may be a refactoring project (to facilitate new sto-ries or simplify existing code), a prerequisite to develop-ment (setting up an environment or installing a database), or an incidental task (writing an interface to third-party ap-plication or defining an API).
UML Universal Modeling Language- a standard for visualizing, specifying, constructing, and documenting software sys-tems.
Use Case A requirements analysis technique that describes a user’s interactions with the system and the application’s re-sponses.
Velocity A measure of the speed of the development team, relative to the estimates in ideal hours. A velocity of 2.0 means that development effort was twice as much as expected (the target velocity is 1.0, which indicates unbiased estimates).
Δ Greek symbol Delta, used to indicate a difference from the traditional XP methodology (per sentence), for purposes of ISO 9000 compliance, CMM implementation, and/or pro-ject visibility.
Requirements
Requirements Analysis
Requirements are defined in terms of functional stories. Customers will define the inter-action between the user and the system for each functional story. Each story will be identified with a name and a number. Δ Stories will be documented in the form of use cases (see Appendix A) and maintained in the business unit’s software development life cycle management system.

Release Planning begins when Customers decide that enough stories have been de-fined for a release. Additional use cases may be created may be created during release planning, if necessary.

Requirements Review
The Project Team reviews the use cases as a group during Release Planning and makes amendments as necessary. The development team and Customers may also meet at any time during design and development if they need clarification on the ap-pearance or behavior of the system.

Requirements Sign-Off
Δ Once assigned to a release, use cases are signed off for understanding by the Cus-tomer and assigned developers using the business unit’s software development life cy-cle management system.


Requirements Changes
Any project team member or other person may request a change to the stories assigned to a release. The results of a spike may also require changes to the original story or re-factoring of other parts of the system.

Δ Proposed changes (including adding or removing stories to a release) will be entered into the business unit’s software development life cycle management system. Changes must be approved by the Customer, assigned developers, and the QA lead for the pro-ject, and must be reviewed and a decision made within two business days (unless there are extenuating circumstances such as illness or vacation, which must be noted on the request). The use cases are modified as changes are approved.

Release Planning
All members of the Project Team are involved in Release Planning. At the start of Re-lease Planning, a metaphor for the release (or product, for a new product) is created by the Project Team to articulate the theme for development of the system.

Prioritization
In addition to the functional stories defined by the Customers, additional technical stories may be necessary, which are described by the development team. If necessary, stories may be split or merged to organize them in a meaningful way and/or decompose large projects into manageable parts. Customers will prioritize each story.

Estimation
Tasks needed to implement each story are defined, and estimates in ideal hours are de-veloped for each task, which are aggregated at the story level. If a plausible estimate cannot be developed for a story (for example if too much about the functionality is un-known or a prototype is required for technical feasibility), a spike will be assigned.

Δ For new products, estimates will be developed for all stories needed to create a sal-able product, even if they may be delivered in several interim releases, in order to per-form a value analysis. Each subsequent release will be planned independently.

Customers may reprioritize stories based on the estimates provided. Developers may revise their estimates based on changes made to the stories by the customers. If the team’s velocity is known, all estimates will be adjusted in order to obtain the expected number of effort hours.


Story Assignment
Customers assign stories to the release based on the estimates and the constraints of the release (for example, if the release schedule is fixed, this will be the number of de-veloper hours available in the release timeframe). XP releases are typically three months or less in duration. Stories will be assigned to iterations within the release and the num-ber and duration of iterations will be determined.

Δ Stories not assigned to the release are inventoried using the business unit’s software issue tracking system. This inventory will also be used to track product enhancement re-quests.

Project Plan Creation
Stories, tasks, and estimates are logged in the business unit’s software project man-agement system. Team members sign up for tasks and leveling is performed to ensure that all tasks are assigned and that all team members have a reasonable workload.

In order to spread knowledge of system components from the original authors to the rest of the development team, coding assignments will pair a developer who is familiar with the area being modified with someone who is not, where such a situation exists (and there is more than one developer on the project team).

Project Plan Review and Sign-Off
Δ The baseline plan is reviewed and a sign-off is performed by all project team members to indicate understanding, using the business unit’s software development life cycle management system.

Project Plan Amendments
Using the business unit’s software project management system, the plan is adjusted when appropriate to reflect the current status. Reports will be used throughout the re-lease to determine the status of the release in terms of progress against the schedule. At the end of the release the actual numbers will be used to determine the team’s velocity.



Design
Design Analysis and Documentation
Design is performed concurrently with development. Δ The high-level architecture for each subsystem will be documented in class and collaboration diagrams and an entity-relationship diagram will be created for the database schema, which will be updated as the design changes.

Class diagrams will reflect the static structure of the system, including inheritance and ownership. Collaboration diagrams will be used to document the interactions among sys-tem components. Patterns will be documented for collaborations that are used through-out the system.

Other design documentation may include video recordings of design sessions and im-ages captured from whiteboards. Δ Electronic design artifacts will be stored in the busi-ness unit’s software development life cycle management system and physical design ar-tifacts (such as videotapes) will be retained by the project manager.

Design Review
Δ Modifications to the design will be reviewed at the end of each iteration and results will be recorded in the business unit’s software development life cycle management system.

Development
Coding
All code will follow the business unit’s coding standard(s) for the programming lan-guage(s) used for the project. Since system documentation is at a high-level, header and in-line comments must fully document the intent and purpose of the code.

Where the programming language supports the generation of technical documentation from source comments (such as javadoc), such features will be used.

Code Review
Code reviews are performed continually through the use of pair programming. Since pair development functions as the code review, all work is required to be done in pairs (or teams, which may be necessary when coaching new project members). Code that is de-veloped individually will be reviewed according to the process defined in the business unit’s Software Development Methodology.

Project Team members may also meet to review code at any time for educational pur-poses.

Unit Testing
Unit Test Creation
Unit tests are written throughout the development cycle. The initial set of unit tests is based on the developers’ understanding of the requirements of the story, and are modi-fied as changes are made and problems are found.

Whenever possible, unit tests are to be automated for reusability. Tests that require a system failure that is not reproducible, such as the loss of network connection, may need to be performed manually. However, manual tests are to be written only as a last resort. In cases where it is not possible, feasible, or economical to create automated unit tests and automated system tests can be developed (for example, when verifying confor-mance to GUI standards), the system tests will be created during development and also function as unit tests.

Unit tests are to be thorough. The use of code coverage tools may be necessary to de-tect dead code blocks and determine that all possible conditions are tested.

Note: unit tests are not necessary for types of errors that will be caught by the compiler being used for the project.

Unit Test Review
Since code will be written to implement unit tests, all tests must also be written in pairs. Individually written unit tests will be reviewed according to the process defined in the business unit’s Software Development Methodology).

Unit Test Execution
All unit tests must execute successfully before integration. Δ Logs containing the results of automated unit tests will be retained on the server executing the tests in a directory specified by the tool being used. Δ Manual unit test results will be stored in the business unit’s software development life cycle management system.

Integration
All application artifacts will be checked out for modification, with strict locking (only one person at a time will be able to modify a particular file). Each developer will have a sandbox to contain a copy of the development environment, including their checked-out files. Δ A comment indicating the story name and number will be entered for traceability when artifacts are checked-in.

Upon check-in of source code, a build will be performed (either automatically or manu-ally, depending on the availability of tool support for the particular development environ-ment). The complete set of all automated unit tests will be run after each successful build.

If the build is unsuccessful or there are errors reported by the unit tests, the developers who performed the check-in will update the code and unit tests as necessary until all problems are resolved.

Deployment
Promotions are performed at certain points in the release cycle in order to deploy the system to various environments. In order to prepare for a promotion, the developer will perform a build of the system and run the unit tests (as described in integration) and checkpoint and label the source code and other configuration items (such as database scripts needed for the release) using the business unit’s configuration management sys-tem. Δ Each promotion will be logged in the business unit’s software development life cycle management system.

During a promotion the executable code and any necessary files (such as data files, help files, and configuration files) are copied from the source to the destination environment. Any necessary changes are also made to the database structure of the destination envi-ronment.

At the end of each iteration, the system will be promoted from the build to the test envi-ronment. Customers may also request a promotion to test within an iteration.

At the end of the release the system will be promoted from the test to the staging envi-ronment. The staging environment is used for product demos and for preparation of the packaging materials for pilot and production installation.

Packaging will be treated as a separate technical story for each release, undergoing all of the development and testing activities in this process. The packaging story must cover new installations and upgrades if applicable.

System Testing
Acceptance Testing
At the end of the last two iterations in the release Customers will have the opportunity to validate that the system implements the stories as expected.

Customers write acceptance tests for each functional story while design and develop-ment is in progress by using the stories to develop test cases. The test script for a story will include verification for the system’s response to each user action. Δ Test scripts will be stored in the business unit’s software development life cycle management system.

After a promotion to the test environment, customers will execute the test cases and will indicate the results in the test scripts. Δ The completed test scripts will be stored in the business unit’s software development life cycle management system.

Regression Testing
During System Testing, Customers will also ensure that changes made for the current release have not caused adverse side effects to existing functionality using test scripts from prior releases. Δ The completed test scripts will be stored in the business unit’s software development life cycle management system.

Δ If the project team has technical QA resources, the test scripts for the stories in each release will be automated after it is promoted to production. Δ The automated scripts will be executed against subsequent promotions in place of manual regression testing, and the logs of test results will be retained on the server executing the tests.

Δ Pilot Testing
If the Customers on the project team are representatives rather than actual users (or the Customers may not be representative of the entire user population), one or more pilot installations will be performed in order to validate the system under expected production conditions. Users involved in the pilot will perform acceptance and regression testing. Defects discovered during pilot testing will be reported to the Customers and tracked the same as problems found internally.

Defect Tracking
Defects discovered during and after System Testing will be logged in the business unit’s software issue tracking system and tracked until closure. If an error is discovered in a manual or automated test script, it will be logged as a defect and the modified test case(s) and any others that would be affected by the change will be re-executed.

Release Evaluation
Any problems discovered during System Testing must be resolved unless Customers agree to enter a project for the issue in the business unit’s software issue tracking sys-tem for resolution in a later release.

The Customers on the project team, QA Lead, and project Sponsor will determine when the application is ready to be released. Δ Approval for release will be performed via the business unit’s software development life cycle management system.

External customers and other stakeholders such as the Customer Support, Deployment, Implementations, and Training groups will be notified in advance of the expected release date. Each external customer will determine when the application is ready to be installed at their site.


Δ Lessons Learned
After the release is complete, the Project Team will meet to review the project metrics and any other relevant observations. The results of the meeting, including suggestions for improvement, will be tracked and monitored using the business unit’s continual im-provement process.

Records

Description Location
Project Plan Business unit’s software project management system
Project Plan Approvals Business unit’s software development life cycle manage-ment system
Project Requests Business unit’s software issue tracking system
Use Cases Business unit’s software development life cycle manage-ment system
Use Case Approvals
(new and modifications) Business unit’s software development life cycle manage-ment system
Class and collaboration diagrams Business unit’s software development life cycle manage-ment system
Design Approvals
(new and modifications) Business unit’s software development life cycle manage-ment system
Unit Test Results Business unit’s software development life cycle manage-ment system (for manual tests)
Development server (for automated tests)
Acceptance Test Scripts Business unit’s software development life cycle manage-ment system
Acceptance Test Results Business unit’s software development life cycle manage-ment system
Regression Test Scripts Business unit’s software development life cycle manage-ment system (for manual tests)
Test server (for automated tests)
Regression Test Results Business unit’s software development life cycle manage-ment system (for manual tests)
Test server (for automated tests)
Pilot Test Results Business unit’s software development life cycle manage-ment system
System Test Defects Business unit’s software issue tracking system
Release Approval Business unit’s software development life cycle manage-ment system


Revision History

Revision Date Section Revised Description of Revision
April 28, 2003 All First Published Revision










Requests for revisions to this document should be submitted to the CCS Product Devel-opment Manager, who is the owner of this document.

Appendix A: Documenting Requirements with Use Cases

Use cases are a technique for documenting the interaction between the user and the system. As such, they are a useful for recording stories in a structured form (similar to a story card). Use cases may be presented in descriptive, tabular, or diagram format. The format to be used will be determined for each project.

Example 1 – Descriptive Format:

The descriptive format is a narrative of the behavior of the system in response to user actions. A descriptive use case should contain the same information as one in tabular format.

After the user launches the application, the logon screen is displayed. When the user types their id, it is displayed in the field. When the user types their pass-word, it is masked with asterisks. When the user presses the login button, the system verifies the user’s credentials. If successful, the application’s splash screen is displayed and the user ends up on the system’s main screen. If the user id and/or password is incorrect, an error message is displayed and the ap-plication shuts down when the user presses the OK button to acknowledge the message.

Example 2 – Tabular Format:

Use cases in tabular format contain the following elements:
• A brief description of the purpose of the use case.
• The normal and alternative flows of control (stimulus/response sequences) between the system and the user, including any reusable sub-flows for the use case.
• Preconditions and post-conditions.


Story #: 123 Story Name: Login to application
Description: Authenticate the user’s credentials and initialize the application
Preconditions: 1. The application has been launched.
Base Flow
User System
Enter user id Display user id in field as typed
Enter password Asterisks display in password field as typed
Press the login button Verify user
Display splash screen (if successful)
[Alternate Flow 1] (if failure)
Alternate Flow(s)
User System
[Alternate Flow 1] Display error message
Press OK Perform shutdown
Post-conditions: 1. The main system screen is displayed (if successful)
2. The application exits (if failure)

Agile team goal

“To deliver high quality, running, tested stories that meet the business need in a predictable, efficient and collaborative manner—on time, on budget!”

Define agile

Agile is an iterative and incremental (evolutionary) process approach to software development which is performed in a highly collaborative manner with ‘just enough’ ceremony that produces high quality software which meets the changing needs of its stakeholders.”

Scrum provides the processes and visibility needed to manage and control complex software and product development.

If you adopt scrum ..team follows these

If you adopt Agile/Scrum, your teams will likely:

* Gather the list of work to be completed as user stories
* Develop a release plan to determine the project schedule
* Estimate the complexity of each story in terms of story points
* Work in small two- to four-week fixed iterations (also called sprints)
* Start an iteration with a planning meeting
* Collaborate within the team and with the business
* Have daily fifteen-minute standups to track progress
* Have a demo at the end of each iteration to review what was accomplished (or not!)
* End the iteration with a retrospective

Top 8 Reasons to adopt agile methodology

Top 8 Reasons Why the Customer to Adopt Agile
--------------------------------------------------------

1.Early measurable return on investment. They want to see working software at the end of each iteration and early in the process.
2.High visibility and control over the project progress. High visibility into project progress can also yield early indications of problems.
3.Early and continuous customer feedback. Because the customer is involved throughout development they end up with software they want and will use.
4.Empowered Product Owner. The PO is given the information necessary to make decisions to steer the project toward the goal.
5.Incremental delivery. Delivery of software on the scheduled release date is not an all or nothing deal.
6.Agile change management is adaptive to changing business needs. Agile and Scrum give the product owner more control over adding, changing, or removing requirements (except for the current iteration stories) than traditional methodologies.
7.Agile helps align IT with the business. Teams work only on the top business priorities.
8.Agile reduces product and process waste. Nothing is developed that isn’t specifically needed. Agile processes are lightweight and value driven.

Top 8 Reasons Why the Team and Management Adopt Agile
-----------------------------------------------------

1.Agile builds empowered, motivated and self organizing teams. Agile produces an increased level of team satisfaction because individuals are empowered to provide input, set the iteration goal, self-organize, and help improve the process. This unleashes the creativity and innovation of the team members.
2.Clear expectations are set and communicated. Both the team and product owners have a clear understanding of the release and iteration goals and what is expected of them to reach these goals.
3.Success is clearly defined. The agile definition of "Done" is accepted by the product owner as completed and ready to ship. The only measurement for success is stories that are "Done" at the iteration and release level.
4.Teams can focus on delivering measurable results. Agile teams focus on getting working software delivered instead of clearing impediments, prioritizing, or being pulled in other directions.
5.Customers communicate directly with the team and provide timely feedback. Early and direct feedback is the only way to deliver what the customers really need.
6.Teams feel a sense of accomplishment and recognition. The team feels a sense of accomplishment at each demo when they deliver stories that are "Done" and hear the customer and stakeholder eedback first hand.
7.Management realizes cost/time savings due to waste elimination and efficiency. Many organizations that adopt agile seek to become "Lean" and eliminated processes that add no value.
8.Better resource management for shared team members. The good thing about time-boxed iterations is that they are time-boxed!
This means that shared members from other teams (DBAs, Technical SMEs, Report Writers, etc.) will know in advance when the next planning meeting, demo, and retrospective are scheduled.

Agile Testing ...Really good one

This video is really good ..this reminded me of all the agile principles back...i love it..

Agile methodology Pays... From internet