Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How do you structure a development sprint? [closed]

Tags:

agile

So I have a backlog of features and we are about to get started on a sizable project. I am working on defining the structure of our sprints and I'm interested in the communities feedback.

What I'm thinking is:

  • One day sprint planning
    • Fill the backlog and figure out what each dev will go after this sprint
  • Three weeks of development
    • GO! GO! GO!
  • Daily stand up meeting
    • Check to see if anyone needs help or feels off track
  • Two days of sprint review
    • code reviews happen here, stakeholder presentations
  • One day sprint retrospective
    • what did we get done in the last sprint? how can we do better next time?

Sprints should always end on a Tuesday (to avoid too much weekend stress).

Anything else? There is obviously more to agile than this. I want to provide the team with a simple outline of how we are going to operate as we get this project started.

like image 972
Eric Schoonover Avatar asked Sep 17 '08 16:09

Eric Schoonover


People also ask

What do developers do at the end of a sprint?

Sprint end - At the end of a sprint, two meetings are held: Sprint review – The team shows their work to the product owner. Sprint retrospective – The team discusses what they can do to improve processes. An important goal is continuous improvement.

What should a development team do during a sprint?

The development team participates in sprint planning that takes place at the beginning of every sprint. In collaboration with the product owner, the development team helps establish the goal for the next sprint. This is facilitated by the Scrum Master.


2 Answers

I'd consider experimenting with sprints that are shorter then one month.

Personally I find one-two week iterations more effective at getting effective feedback quickly. It also prevents any issues that may be causing problems at the iteration level building up to levels that become harder to manage.

Even for the 30 day sprint - two days sounds about a day to long for the sprint review... and one day sounds about 0.5 days too long for the retrospective. I've found that if you need much more than that there have been communication problems while the iterations has been going on - so you might want to look at needing long reviews as a possible red flag.

Of course that's just been my experience - of mostly developing web apps with smallish (4-12) person teams. You're experience may vary.

That said - I'd definitely give shorter sprints a try. Like integration builds - a lot of things get easier if you do them more often.

like image 138
adrianh Avatar answered Sep 19 '22 15:09

adrianh


Turn off email, cell phone and instant messaging apps for core code time. 10am to 1pm, 2pm to 5pm might be good blocks for this.

Order food, drinks for team when they are in "the zone".

Cancel all other meetings for the days of, before and after the planning session and the review days.

like image 30
sal Avatar answered Sep 21 '22 15:09

sal