The burndown behaviour will change.

Before, all values for all previous days were calculated on the fly. This was time consuming. However:
- adding a story after the sprint had started would affect the remaining effort from the date added onwards.
- removing a story after the sprint had started would affect the remaining effort for all previous days.

After,
- adding a story after the sprint had started would affect the remaining effort from the date added onwards.
- removing a story after the sprint had started would affect the remaining effort from the date removed onwards.
- the first time a burndown is displayed after the corresponding code is deployed, there will be no improved performance. However, when reloading the page or someone else viewing it afterwards, the burndown will be shown much faster.


The remaining effort on the cardwall will change.

Before:
- the remaining effort on the cardwall was equal to the sum of the elements the user had the permission to see.

After:
- the remaining effort on the cardwall represents the remaining effort of the sprint, regardless of which stories the user has the permission to see. The side-effect of this is that in some permission permutations, the user will see a remaining sprint effort of 10, say, whilst there would only be one visible story on the cardwall with a remaining effort of, say, 3. However, this story includes some complementary UI change so that this scenario would make sense.


All calculated fields will change so that the values are no-longer calculated whilst taking into account permissions. This would mean that each such field has an exact same value for all users at all times. If the value is sensitive then it can still be managed in the field permissions.


Note:
- this story is number one out of two. It does not deal with the performance whilst calculating remaining effort on the present day. Another story will cover that.

- do not check permisions of linked artifacts.
- announce that calculted fields' behaviour will change and that permissions should be managed on these fields.
- take into account the behaviour change on a milestone cardwall (sum of cards may not equal remaining effort)
- store values for previous days in database