How could jira fix the incident high priolity requirement

chundu

Hello, we've met some customer that have problem to deployment the agile concept. Because there's some sudden need from the sales. Then the new requirement may result the suddenly urgent requirement. The manager would force assign to the team member to do the additional work . There's no more people to resolve it. Is there any resolution for these reality issue meet by companies?

By example,there's a conference to show the new product in 1~2 day.

After fix that new sprint, then return the old sprint to continue.

Is it possible do that?by latest jira?or future jira?

Phill Fox

Firstly I would remind you that the aim of Agile is to support your business needs. 

So taking the new requirements as a business need means you need a process that supports this.

Considering a "Scrum" approach with sprints which allocate a set period of time to complete a pre-determined set of activities does not readily lend itself to "sudden demands" we need to consider how these can be effectively handled. The following are realistic options for managing this sort of business need in the longer term.

1. Add the items to the sprint, estimating the size and remove some non-started items from the sprint of the same size. This allows you to retain the velocity of your sprint and not alter the duration. It will also encourage the stakeholders to realise the impact of introducing new items mid-way through a sprint because of the impact upon the deliverables.
2. If the "sudden demands" are more regular you can always allocate in each sprint an amount of time for this type of item. If none occur then bringing in more items from the backlog can be done during the sprint.
3. Or as you suggested you can abort the current sprint, deal with the sudden request and then either resume the sprint or start a new sprint.

Now as sprints are usually designed to deliver a set of deliverables that tie together all of the above options can be quite disruptive. If however, the items are gathered together more as an administration action than because they are truly linked then maybe you should consider the "Kanban" approach where the backlog is continuously prioritised and items can be dealt with in turn. So a sudden demand just moves to the top of the priority list with the stakeholders agreement and understanding of the impact on other items.

 

What I would strongly discourage is any concept of trying to get more out of the team than they have planned to do. As they should have considered capacity, capabilities, dependencies when agreeing to the sprint.  A one-off request for additional effort could probably be covered but if this was to become regular then there needs to be a recognition of this and plans put in place to deal with it.

 

I hope this provides you with some options to consider and you may even have other ideas, my key focus would always be on working out a method which supports the business need.