Easy Redmine goes Agile

Basic characteristics:

• 2 weeks long sprint
• sprint is finished = new version is released = next milestone in road map

• sprint backlog is frozen after initialization (no more tasks are added), unless critical bug comes
• other than critical bugs → bugfix delivered in the next sprint = max 4 weeks delivery time

CTO Monday Morning

• Gives time estimates for all the bugs reported in the last week

Management Meeting 

• Account managers come with new feature requests
• Discussion over them → solution + time estimates
• Account manager informs customer back

Sprint Initial Meeting (1st week, backlog creation)

• Sprint backlog is created
• bugs (A-clients, B-clients) status: estimated
• small & effective feature requests status: customer approved
• Sprint volume is checked in week Resource Management – due date is automatically set when the issues is placed into the Sprint

Sprint Revision Meeting (2nd week, revision)

• Sprint is reviewed
• some bugs are prioritized
• critical bugs may be added

Stand-up meeting (every day at 10am) Account managers → programmers

• Accounts meet programmers for updates
• Programers return finished tasks on branch domains which can be shared with the customer – however delivery in the next release – mean time is the space for testing and approval
• customer can obtain bug-fixed version 
• Accounts & programmers drive „sprint backlog → new → consultation → code review -> done" process

Bugs in the practice

• Bug, statuses:
  • new -> CTO estimates
  • estimated -> ready for the sprint
  • realization -> in the sprint
  • consultation -> account controls
  • code review, merge request -> CTO merges in GIT
  • done -> merged in the coming version
• Arrives in the system (new)
  • Support manager evaluates whether bug is critical or not
  • Non-critical → assigned to CTO (or deputy) for time estimate
  • Critical → ah doc solution → should be added into the running sprint
• Sprint initial meeting
  • VIP + Hosted clients' bugs are prioritized
  • bug is placed into the sprint = bugfix delivery in the next version
  • programmer is assigned to the bug 
  • Account drives bug fixing with programmer on stand-up meeting
  • Account communicates with the client
• Delivery with the release
  • customer can obtain bug-fixed version sooner

Feature requests in the practice

• Feature Request, statuses:
  • new,
  • estimated,
  • canceled,
  • approved by client,
  • canceled by client,
  • realization,
  • consultation
  • code review - merge request
  • done
• account managers comes to management meeting with new feature requests (new)
  • discussion about the solution (approved, canceled) + time estimate from CTO
  • account manager informs client about yes/no + time estimate
  • Only „approved by client" feature requests can be placed into the sprint
• Sprint Initialization Meeting
  • feature request is placed into sprint backlog (in the sprint)
  • Client is informed about delivery time – 2 weeks
  • Account manager drives realization on stand-up meeting 
  • Delivery with the release
  • customer can obtain version with new feature sooner