Skip to main content

AX and Scrum: Story

I have posted previously on AX and Scrum this is just a continuation of my series.

This post shall cover what a story is. A user story is a short description of what is needed. The main purpose of this is to be able to estimate the piece of work.

Below is an actual story i have worked on.


We could (should) have written this different. In scrum they teach you to write it in the perspective of the actor. For example: “As a work order user, I would like to create a work order and submit it to workflow. I would like to get alerts and notifications.”

One thing we like to do in our team is set up Acceptance criteria's (those AC1 2 AC5 that you see in the screenshot). At the end of the day we use it to tell us a story is done.

The next step for use once we have given it sized the story and accepted it into a sprint. We start putting some finer details. We break down the task.

Our comment tasks that we use and to use to indicate a story is done are:

  • Functional design – Doesn’t have to be a full functional document to describe every detail. We use this as an agreement document of what is going to be built and helps us think through the solution before we do any development. Sometimes this can be bullet points but it is encourage to at least write up the business requirement and what we are trying to achieve. It should also work through ticking the acceptance criterias too.
  • Technical design – A technical document usually involves an ERD (UML diagram). If description of what's been done and describe complex functionality.
  • Development – Start coding.
  • Functional review – Usually when a developer and another functional person work together and see if they are on the right path. Back and forth till development is done.
  • Test cases – Write up test cases. This doesn’t have to wait till development is done. This can be done and sometimes it is good practice to do it before development. Developer knows what to test against and how to test the piece of functionality.
  • Unit testing – Now that the developer has finished development and it is checked in to the TEST environment. Someone else can start testing. Developer can fix any bugs/issues etc.
  • Functional integration testing – At this stage all the stories are done and a FIT environment is built. We start testing as a whole through. Use another person other than the guy who did the unit testing. Methodically go through the test cases written up. Automated testing and performance testing is done.
  • Online help – All forms need online written for them. Any procedure documents etc.
  • Release notes – A brief description of the functionality. This is good when we send out our emails to say what has been achieved in the sprint.
  • Implementation documentation – This is a document that is updated every sprint. It is a guide for implementers on how to set up the system. What/Why and How?
  • User acceptance – Usually when we go through the functionality and present it. This is done regularly but done formally during the sprint review.

The above tasks are pretty comprehensive and allows us to estimate how long a story takes as each task is estimated in hours. This is not set in concrete but this is what we do.

The results you see on a series of posts. The overview contains a flow diagram that was roughly documented as part of the functional design.

Popular posts from this blog

AX - How to use Map and MapEnumerator

Similar to Set class, Map class allows you to associate one value (the key) with another value. Both the key and value can be any valid X++ type, including objects. The types of the key and the value are specified in the declaration of the map. The way in which maps are implemented means that access to the values is very fast. Below is a sample code that sets and retrieves values from a map. static void checkItemNameAliasDuplicate(Args _args) { inventTable inventTable; Map map; MapEnumerator mapEnumerator; NameAlias nameAlias; int counter = 0; ; map = new Map(Types::String, Types::Integer); //store into map while select inventTable { nameAlias = inventTable.NameAlias; if (!map.exists(nameAlias)) { map.insert(nameAlias, 1); } else { map.insert(nameAlias, map.lookup(nameAlias) + 1); } } //retrieve fro

AX - How to use Set and SetEnumerator

The Set class is used for the storage and retrieval of data from a collection in which the values of the elements contained are unique and serve as the key values according to which the data is automatically ordered. You can create a set of primitive data types or complex data types such as a Class, Record or Container. Below is sample of a set of records. static void _Set(Args _args) {     CustTable       custTable;     Set             set = new Set(Types::Record);     SetEnumerator   setEnumerator;     ;     while select custTable     {         if (custTable && !         {             set.add(custTable);         }     }     if (!set.empty())     {         setEnumerator = set.getEnumerator();         setEnumerator.reset();         while (setEnumerator.moveNext())         {             custTable = setEnumerator.current();             info(strfmt("Customer: %1",custTable.AccountNum));         }     } } Common mistake when creating a set of recIds

Approve Workflow via email using template placeholders #Dyn365FO

Dynamics 365 for Finance and Operations has placeholders which can be inserted into the instructions. Normally you would want this to show up in the email that is sent. One of the most useful ones is the URL link to the exact record that you are approving. In the workflow configurations use the placeholder and build up your message. Towards the end it has workflow specific ones. The URL token is %Workflow.Link to web% . For the technical people the token is replaced in this class WorkflowDocumentField. This is what I inserted into my email template. <BODY> subject: %subject% <BR> message: %message% <BR> company: %company% <BR> for: %for% <BR> </BODY> Should look like this. The final result looks like this. If you debug these are the place holders that are put together.