I have been asking for this for years.

the request object is ideal for tracking the governance aspects of Portfolio and work items moving into and between backlogs. I assume it is its primary purpose.

To make this fit for purpose a KANBAN Board to manage requests is really needed with associated management reports.

Please consider a revisit on the request management feature to sort these things out.

Comments

  • How about this: make an epic called Requests, make stories in it, and leave the status blank so the clock doesn't start. Then when people start to work on a request, move the request-story out of the epic, start planning it, etc., etc.

  • We have been doing this, however this prevents us from using features/epics for their intended purpose.
    VersionOne has the request object to deal with the governance of Backlog items moving into and out of backlogs. This is quite appropriate when using an Agile tool in a financial/banking environment.

  • Come on V1, lets have boards for the main system objects/Tx

    Give Requests a refresh

  • Please (re-)consider addding Kanban board for requests. We would like to track and prioritize client requests using the V1 Request object.

  • This is needed urgently. We should be able to visualize flow of requests.

  • VersionOne treats Requests as a "one off" meaning that Requests sit outside of the normal workflow of Portfolio items and their children.

    As a result, Requests are easily forgotten and can stack up. Another issue with Requests is that information about them cannot be visualized using Kanban boards. This feels very un-Agile. A Kanban board with functionality seen in Team Rooms can add useful visualization and incentive for those responsible for working Requests.

    This would require flexibility such as what the Team Room has for work flow column definitions, Threshold, and possibly WIP limit definitions that can be applied to the Kanban board

    I have seen two instances where Kanban board functionality would be useful.

    1. Product level new work intake
    I'm assuming this is probably the default use of Requests.
    1. A Request for a Product change comes into the Product Owner or Product Manager
    2. Request is reviewed and additional information acquired if necessary
    3. If the Request is approved a new Epic / Feature / Story (whatever is
    applicable) is created. The Request updated, marked Approved than closed.
    4. If not Approved, the Request is updated, marked Rejected than closed

    A Kanban board would be helpful not only to have a visualization, but also by using the Threshold capability, this could help alleviate the
    problem of Requests being forgotten about and not managed.

    2. Higher level such as value stream / solution / portfolio new work intake. Basically an Enterprise sized organization
    Requirements:
    - New Requests are first reviewed at the Solution level. This review needs to
    complete in X number of days. For example 3 days.
    - The process for downstream areas to know a Request is ready for review should be
    as frictionless as possible, and ideally using VersionOne functionality
    - If a Request passes the Solution level, all of the downstream teams / SAFe
    trains possibly impacted need to review. This review needs to take place in 10
    days
    - Downstream areas will indicate impact in VersionOne
    - Time criticality is more important in this example since review also needs to be
    done by downstream areas.

    This type of example is where adding the Kanban functionality which matches Team Kanban would be the most useful. Potential implementation using Kanban board functionality.
    1. When a new Request comes in it starts out in a Backlog column.
    2. As soon as a Request is picked up for review, it moves a column to the right.
    For simplicity, I'll call this Review in Progress. There is a Threshold set of
    3 days. Just like the Team Room Thresholds, VersionOne's Aging field will
    indicate when a Request is getting close to (yellow) or has exceeded (red
    orange) the Threshold
    3. If the Request will be rejected, it is updated and goes all the way to the
    right of the Kanban board, to a Complete column
    4. If the Request is Approved at the Solution level it then moves to Review Done
    column. This is the visual trigger for downstream areas to review. In addition,
    VersionOne functionality can be used as individuals can get an email alert as a
    Request moves through the board.
    5. The first team / train to review moves the Request one column to the right to
    Downstream Review in Progress. (perhaps there should be explicit policies on
    when to move to Downstream Review in Progress). This begins the 10 day clock
    which VersionOne is tracking via a defined Threshold
    6. Once the Request has completed downstream review (explicit policies should
    probably be defined for this) and is updated appropriately, the Request is
    marked Approved or Reject than closed.

    With this example, a Kanban board provides the following benefits:
    - Readiness is indicated by the kanban board column
    - Since time criticality is important, the Thresholds provide incentive to get
    Request reviews completed on time
    - The information radiator provides at a glance status and highlights where the
    flow is taking longer than expected (hopefully)
    - Built in VersionOne tracking and custom reports can be used to report how well,
    or not well, the process is meeting it's time limits

    I realize the easiest solution for VersionOne users would be to re-purpose Stories and not use the built in Request object. But if VersionOne is going to have a Request object, it should be useful. Hence these examples