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


Additional information
Free Trial

Easy Redmine upgrade
Top plugins & features
New & mobile design
Server upgrades
Global cloud

Start Free Trial

Try Easy Redmine in a 30-day free trial

Full-featured, 30 Days, SSL protected, Daily Backups, In your Geo Location