Sprint is generally 2-3 week event, but can be of 1 week or 4 weeks too, to develop some user stories.
Below images give some idea on Sprint. It starts with Sprint planning, in which we choose the user stories to develop and ends with Sprint review in which we review what we have done.
"Scrum Framework" by Source (WP:NFCC#4). Licensed under Fair use via Wikipedia - https://en.wikipedia.org/wiki/File:Scrum_Framework.png#/media/File:Scrum_Framework.png
"Scrum process" by Lakeworks - Own work. Licensed under GFDL via Commons - https://commons.wikimedia.org/wiki/File:Scrum_process.svg#/media/File:Scrum_process.svg
I am working on totally Agile project using Scrum framework and since everyone has his or her own way of doing things, the Agile is also bit twisted by everyone to adhere to a organization goal. My ideal way of doing a Sprint is 3-week Sprint.
Before start of Sprint we do Sprint planning with big motive of coosing user stories from product backlog and placing them in Sprint backlog. In Sprint planning all we have to do is choose user stories. I have found that initialy people show interest in these planning sessions, but later on these meetings become boring.
I have seen some scrum masters suggesting standard way for deciding story points, but I disagree I think poker session is fun part of Sprint meeting. A story point is like T-shirt size which is based on more on complexity compared to time because we are working in time box system., but its size. A better explanation is on - http://scrumorakel.de/blog/index.php?/archives/48-Estimating-relative-sizes-e.g.-story-points.html. If a user story is big and can't be completed in a Sprint, it should be further broken into multiple user stories, but a user story doesn't contains user stories, it contain tasks. Epic is broken into multiple user stories and a user story is broken into multiple tasks.
A Sprint is created with Sprint backlog at the end of Sprint planning. In my experience user stories are all in To-Do status right now.
Throughout the Sprint the development team can update the Sprint backlog.
15 minutes meeting where every developer (not scrum master or product owner) answers below questions:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
And development team member asnwer to complete team not to scrum master or product owner.
I generally manage the daily scrum call, what I do is when I send meeting invite I also send above questions in the meeting invite, so that developers are ready with answers. Developers one by one, in alphabetical order, update in meeting by answering the questions. For a global team we used WebEx to conduct calls at fix time 1 pm everyday for any Sprint. We talk only about one sprint, we dont know at what time or where daily scrum calls will be arranged for next Sprint.
Big point to note is we dont solve any problem in this meeting, but we do mention any impediment we face or see.
On the last day of Sprint or after Sprint we do review, Sprint Review, which is an Informal meeting to present what was done in Sprint to scrum team and stakeholders. Generally presentation is of increment and feedback is collected along with answering any questions raised, and meeting should not go beyond 4 hours.
Sprint review session begins generally with a presentation in which Product Owner discusses what is done and what is not done, development team demonstrate the work done in sprint, a tester might give testing updates, development team member can give details of governance activities, and product owner can present product backlog.
A preview on what to do next and input for next Sprint planning; review of goals, timeline, and budget; and revise the product backlog.
"The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint" - http://www.scrumguides.org/
Sprint Retrospective, a max. 3 hr meeting, is done after Sprint Review and before next Sprint planning.
It is also mentioned in scrumguides that
The purpose of the Sprint Retrospective is to:
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its work
In my experience we shared on wall three columns:
What went well, What went not well, and What do we want to improve.
The columns can also be named as with meaning nearly same:
What went well that we want to continue, What we can do diffrently, and Action Items
Each development team member asnwer these questions such as one below:
In a typical Software firm we dont just deal in development and meetings, we have lot of surrounding activities, which are lot more critical. A sprint is not only abouty development, we have look after testing and delivery too along with lot of governance activities and documentations.
An ideal scenario -
An ideal scenario is a successfully implemented Agile project. I have seen a project in which we had delivery every three weeks