How to tell the correct story

  • Comments 2

Hello all,

today I want to write a little about something, what is may be known and obvious to someone, but still it is good to talk about it. As a developer, I am on the side, which is creating customizations/modifications/add-ons in Microsoft Dynamics NAV based on the customer requirements. In many cases,the requirements are created by people, which are not technically focused. And because technically focused people talking with different language than end-user or consultants, I want to try to show you some tips, which can make this communication better.

Task description

When customers are asking partners/developers to make some changes, they are giving the task written in different way. Sometime, the problem is described in technical language like:

“Add new field named “Original quantity req.” into Purchase Line table and fill it with same value entered into field Quantity, before the document is partially or fully posted”.

Ok, the task is clear, but: when developer hits some conflict with different functionality, he do not know what to do. He will do only what is described, he will not think about it. E.g. what about quantity in base unit of measure (it is good practice to have both in the line)? What about different table used to post some purchase documents? What about tables with posted documents? “Mission” of this task is unknown. The meaning is not there…

Another description:

“We want to know the quantity, we ordered on the purchase order”

Hmm, ok, there is field “Quantity” on the purchase order. What is the problem? They do not know how to use it? After this, developer/consultant will discuss with the customer this and they will find out, that problem is, that if not all quantity is received by the vendor and user change the quantity to the received one(to be able to close/delete the order), customer do not know the original quantity anymore. It means, again, it is not describing the problem, which must be solved, it is just a wish, which must be discussed.

How to write the task description? Try to write it as “User Story” (in some methodologies is the requirement named “User Story” and I think that it is good name for it). It means something like this:

“As an purchaser I want to know the original quantity ordered, when the order is only partially received and the quantity on the order is decreased to the received quantity to be able to close the order”.

This description gives developer main things he need to know: who (purchaser), what (to know the original ordered quantity), where (purchase order), when (partially received). The “mission” is clear. Technical solution is on the developer, he is the one, who will “solve” the problem in a way, which is most suitable for the system with all the consequences.

“Done”

Of course, as a customer, you may have some specific requirements for the solution. Or sometime, it is hard to accept the created solution. From developers side, sometime the customer say “it is not what I want” (even when it is fulfilling what was described) or “it cannot be like that”. Than it needs long time or too many resources to solve this conflict. In many cases, this kind of conflict begins, when each side have different meaning for “done”. Developer is “done” with the task, when he somehow allows user to see the original quantity (e.g in Change log). User will be “done” when he will see the quantity on the archived order line or on the posted receipt line. Thus, it is a must to have simple and easy points, which could be answered Yes/no, which defines the “done”. Something like this is named Acceptance criteria.

1) Original quantity ordered must be visible on the archived purchase order line

2) Original quantity cannot be changed after order is released

3) The value of original quantity must be easily used in reporting

If you create something like that, it is easy answer "Yes/No” and which point is not fulfilled. Even for developer it is easy to think about the solution and check, if all points are met with it.

“Mission”

And do not forget to tell your partner the main “mission” you have for the whole system, like: Data quantity - you want to focus on count of data user needs to enter manually, Process simplicity -  complexity of the process, UI simplicity - complexity of the UI, Performance - system performance when creating reports etc. Again, it will help your partner to focus the solution in correct direction.

Conclusion

Try to describe tasks as User Story. Add acceptance criteria, which could be answered Yes/No, to define the “Done” state. Try to give context and the problem description, not the solution itself. Developer/partner is responsible for the solution to be in-line with rest of the system. If he is not able to do that, find another partner. Give the partner your visions.

For developers: keep asking “Why” till you find out the original problems, which must be solved. Do not solve the consequences, solve the cause.

 

I wish all of your Happy New Year and many task solved without problems.

 

Kamil Sacek

  • I usualy try to prepare request using "User Story". Functional Consultant ask "User Story" from customer. He try to make solution using the standard functionality. If he cannot, he write functional design based on "User Story" to Technical Consultant. Technical Consultant has excellent knowledge about NAV architecture and he make technical design. Developer need to make code based on design...

  • Good posting. Thank you!