@DavidH071

Hi David,

Great for reaching out with your questions and that you and the team are trying to master Pega. I would urge you to create questions in the collaboration center for the things you seek assistance with as there generally you get a quicker response and this 'Ask the Expert' is more focussed around the Pega Express Delivery Approach. 

That being said; happy to try to help you a bit further. First of all I would like to advise to work through this community page: https://community.pega.com/knowledgebase/articles/case-management/85/assigning-tasks-users as it gives a good overview of the ways to assign tasks. 

I am not really sure what the starting position is but assuming that you have an assignment step in side a case and you want to be able to transfer the assignment to another operator. So you can make use of local actions as extra options inside a process. That will allow you to add a flow action to transfer the assignment to someone else.

So if you open the process in that stage: When you have the process open you can double click the assignment and in the modal window scroll down to advanced and then open local actions. Use pyTransferAssignment as an OOTB transfer flow action. 

Then when you run your case and you reach the process, you can actually open the actions dropdown where you will see the transfer assignment. Clicking that brings you to this action and you can assign it to someone else. 

If you just want to change the stage, then you dont need to do anything as there is an OOTB action for that available. When you transfer the assignment, after the submit then it will be immediately placed in the worklist of that operator. 

Regarding the notification; there is an OOTB option to use for this. On the case, go to settings and select notifications. 

Regarding the requirement to decide at the end to whom to assign the assignment to; it might be easier to use a workbasket for a team. That way anyone can pick it up without explicitly assigning to someone. Either by people taking it from the list (pull) or by using get next work (push). 

Lastly I would like to advise the low code app builder academy mission to you as this gives a great overview of how to create cases in Pega: https://academy.pega.com/mission/low-code-app-builder/v2 

Goodluck!

Dion

@RalphBooth

Hi Ralph,

Yes, I can share some thoughts on the Definition of Done and how to assure that the user stories are brought to done in our build phase.

Obviously, the concept of ‘Definition of Done’ (DoD) is important in Scrum and focusses on defining what “done” actually means. Within a team people can easily have different views on what it means for work to be completed. In short DoD is a shared understanding within the team on what it takes to make your Product Increment -in this case the user story- releasable.

And while DoD is a Scrum best practice, Pega Express meets and extends this by delivering us tools and best practices to support it.

There is however not a single version of a DoD; what good looks like depends on the project, the team and the client context.

There are three important components in the DoD:

1. Business requirements

This talks about the business value that the functionality should bring. The DoD needs to always include checks that all the acceptance criteria are met. There are multiple ways to do assure this. Possible actions here are:

• Prepare a show and tell for the business users
• Approval of the product owner as a signoff that the user story is functionally complete
• Test scenario proofing that the acceptance criteria is met

Testing the user story is very important. My strong advice is when you start designing how to implement a story that you directly define what needs to be tested and proofed and how you will test this.

And as the functionality when passing DoD is releasable, a great feature is toggles inside of Pega. This would allow to directly have the functionality deployed to production but not made available to the business users yet. Then with the toggle the business owners can decide when they want to make this feature available.

2. Quality

In any software delivery high quality software is crucial for long term success. You don’t want to start with instant technical debt as you know this will carry along for a long time. In Pega we have some great quality tools to support, like the test automation features such as Pega unit test or the quality dashboard that will provide insight into the compliance score (guardrails) and the test coverage. Good actions for the DoD here are:

• Test automation case are created and tested
• Implementation is peer reviewed and/or a merge review is performed
• Nu unjustified guardrails (and a proper justification does not state ‘as per requirements’ but it gives a business reason why this guardrail warning cannot be prevented)
• UX Review
• Regression test successful (to proof your added functionality doesn’t break anything else)

3. Non-functional requirements

Although this could be added under the quality category, it is often missed and therefore important to explicitly call it out. These talks about the standard characteristics or attributes of the product that might not add direct business value but without it cannot be released. It defines system attributes such as security, reliability, performance, maintainability, scalability, and usability; they serve as constraints or restrictions on the design of the system. You can find some of this written down as acceptance criteria, for example about the performance of a screen refresh.

Security is an important topic to mention. Every delivery must leverage the security checklist as this provides Pega's leading practices for securely deploying applications. But for the DoD it can prove helpful to add actions such as:

• Perform rule analyzer (RSA) in case of custom code.
• Add privilege to all applicable rules
• Check security events for changes in the security administration
• Extend the role to control access for the new functionality

As said, there is one size fits all. But when you make sure these three categories are taken into perspective with the whole Scrum team in the context of the client, then you will be able to assure a strong DoD. And its not something that is set in stone; its there to help you as a team to assure the functionality is done. If it doesn’t work, has too fine grained checks, you can adjust it.

But one thing is crucial; if the story does not meet the Definition of Done, it is not done!