IT Project & Request Board Procedure

How do tasks get on the request and project boards?

When email is sent to one of the software request queues a pulse is automatically
created. These request boards are monitored by their respective BAs. The BAs will
then complete the pulse and fill in the missing information. Once complete they will
determine if the request is a bug or not. If it is a bug it will get assigned to a developer
by the BA. Any items that are not bugs will be placed in the proper category
( Enhancement, New Feature, General ) and then later moved to the “future” board for
their respect software product. When it’s time for a new release to be decided on all the
open items will be presented to the business users so they can make a determination
as to which items should be in the next release. When a decision is made a new
release specific board is created and these items placed in there.

Project board task movement

Move to Pending
Once a task is moved to a project board the BA will set the phase to “1 Pending” and
using the update area @Mention the business user to gather the necessary information
in order to fully understand the requirements of the request.

Move to In Development
After the requirements have been gathered the BA will assign to the developer and
using the update area @Mention the developer that they should work on this task when
they are finished with the task they are currently working on. Once the developer
begins working on the task they will change the phase to “2 In Development”. If the
developer has further questions for the business user they will use the update area and
@Mention the business user in order to have their questions answered.

Move to In QA
Once the developer has finished the task and they have performed their unit test to
make sure the code is working properly based on their understanding of the
requirement they will use the update area to @Mention the QA person on the team and
inform them that the task is ready for the QA phase. When the QA person begins
testing they will change the phase to “3 In QA”.

If the QA testing fails the QA person will @Mention the developer and explain the results
of the test and what needs to be done to fix the issue. When the developer begins
working on this again they will change the phase back to “2 In Development”.

If the QA testing succeeds the QA person will @Mention the business user informing
them that the code has passed the QA phase and is ready to be tested by the end user.
Move to In EUT
When the business user begins their testing they will change the phase to “4 In EUT”.

If the end user test fails they will use the update area and @Mention the developer and
explain why this failed. When the developer begins working on this again they will
change the phase back to “2 In Development”.

If the end user test succeeds they will @Mention the BA and inform them that the code
meets their requirements and works as expected.

Move to Ready for Prod

When the business user informs the BA that the test was a success they will change the
phase to “5 Ready for Prod”.

Move to Released to Prod

Once all the tasks on the board are marked as “5 Ready for Prod” the release is
complete and can be scheduled to be rolled out. Once the roll-out date is determined
an announcement will be made on the Info Tech -> IT Announcements board informing
everyone of the scheduled release date and time.

When the code has been moved to production the BA will change the phase to “6
Released to Prod” and the release is now considered complete and deployed. This
release board will be archived after the next release is deployed.