Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Scrum Agile Framework

Basic Sprint process

  • Stand-up each day (scrum team including scrum master / product owner if appropriate)

  • Sprint Review with stakeholders and scrum team at end of sprint; could be after sprint ends

  • Sprint Retrospective at end of sprint to work out what went right/wrong + improvements to process

  • Sprint Planning at end of sprint: plan stories for next sprint

    • Sprint Pre-planning Indigina/iTransition as preparation for upcoming sprint planning meeting

Continuous Process

  • User Story Refinement

  • Requirements derivation

  • Prioritisation

Determining Project Timelines

Estimation

User story estimation

Estimation of each user story is done using “Story Points”. This is an established agile technique and is the recommended method for development teams in terms of effort, rather than estimation in terms of time. iTransition also strongly recommend this estimation method and have seen more successful outcomes in this way.

Velocity derivation

A number of story points is given for each user story and within a fixed time (sprint) a velocity is eventually established per team or per individual which is the number of story points achieved within a given time. After enough sprints have been run the velocity will tend towards a more consistent value as experience is gained in all aspects of the development cycle from requirements to testing.

Timelines

As the process progresses and matures the velocity of the development team will begin to settle down to a figure representing the average amount of effort (story points) which the team can deliver in a given timeframe. From experience this will take around 3 sprints (6 weeks). It depends on

  • Accuracy and detail of user stories

  • correct breaking down of tasks, correct architecture

  • Prioritisation to keep within parameters of MVP

  • Amount of working time available to each developer

  • Communication quality between

    • Developers

    • Technical Architects

    • BA

    • Product Owner

Roadmap and Gantt chart

Expecting to create a roadmap and gantt chart for expected deliverables for each sprint (2 week period). However the speed of delivery of the roadmap and gantt chart details depends upon the stories and prioritisation. Initially the information will be limited but by end of April expecting a few weeks planning to be available.

Agile processes do not lend themselves well to actual dates for delivery however what they do is allow planning to take place within sprints as long as user stories are specified well enough. In order to produce a proper Gantt chart there needs to be a story point to time equivalent conversion. There also needs to be a space for team members to be recorded as absent so that they are not expected to be working during that time.

  • No labels