Easy Redmine goes Agile
Get to know how do we use Easy Redmine Agile Board for development of Easy Redmine :-). Whole process is described here.
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
22.08.14