ArcherPoint Microsoft Dynamics NAV Developer Digest - vol 9
The ArcherPoint technical staff—made up of developers, project managers, and consultants – is constantly communicating internally, with the goal of sharing helpful information with one another.
As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.
Matt Traxinger shared Satya Nadella’s (Microsoft’s new CEO) open letter to Microsoft employees:
Take a look at Mr. Nadella’s vision for the future of Microsoft.
From the open letter: “We'll push forward and evolve the world-class productivity, collaboration and business process tools people know and love today, including Skype, OneDrive, OneNote, Outlook, Word, Excel, PowerPoint, Bing and Dynamics.”
Jon Long on a bug in Dynamics NAV 2013 R2 Reporting – Header out of sync with lines:
Report Bug - Header out of Sync with Lines(2013R2, probably all rollups):
Once NAV encounters a page change on a report with more than 1 page, the Header gets out of sync with the lines, only in batch reports, and only if it's not the last report in the batch.
I opened a MS ticket. The fix that Microsoft suggests is to change the margins on the report to T.25,B.25,L.5,R.5. However, that only fixed it in the base NAV Report. To get it working properly in one report, I tinkered with the margins. I finally got it to work by decreasing the height of the line (the single Purchase Line) to .15509in from .25. (.15509in is the default for the Purchase Order report).
So, it appears the Base Reports (all of them) have a bug that will confuse the header, i.e., the header is incrementally out of sync with lines. It seems to be only when one row is orphaned on the last page of any multi-document batch report. But, I'm not 100% sure. Somehow, the margin change fixes it, but, I think there’s more to it than that. Microsoft did acknowledge that they had heard of this before, but Cronus does not have enough data in it to reproduce the problem. They also said they do not have an official fix for this yet.
Dan Sass shared an interesting article from Harvard Business Review blogs on how continuously checking email can seriously affect your productivity:
The Cost of Continuously Checking Email
From the article: “[One study showed that] regaining our initial momentum following an interruption can take, on average, upwards of 20 minutes...[while another study] found that we lose as many as 10 IQ points when we allow our work to be interrupted by seemingly benign distractions like emails and text messages.”
Check out the entire article.
You might also be interested in ArcherPoint’s own blog on the subject – read Hannah Horning’s blog, The Truth about Multitasking.
Dan Sass shared an article from MSDynamicsWorld.com on Microsoft’s announcement on the next major release of Dynamics NAV:
Microsoft Dynamics NAV 2015 will be the next major release, due later in 2014
Alan Campbell on SPI:
The SPI (Schedule Performance Index) is a measure of progress achieved compared to progress planned on a project. It is used in conjunction with the CPI (Cost Performance Index) to forecast the final project completion estimates. An SPI value of less than 1.0 indicates that less work was completed than was planned. An SPI greater than 1.0 indicates that more work was completed than was planned.
The classic SPI calculation is EV (Earned Value) / PV (Planned Value), but since our project approach is Agile we can turn to story points to simplify the calculation. We can use the story points earned by the team instead of the classic EV, and we can use the story points planned by the team instead of the classic PV value.
Here is a simple example to show how it works. In the first two sprints the team planned to deliver 100 story points per sprint for a total of 200 story points; therefore the PV = 200. In the first two sprints the team delivered and earned 190 story points; therefore the EV = 190.
We can then calculate the SPI as 0.95 which was derived from taking 190 / 200 . An SPI of 0.95 shows that we are behind schedule in the project. The team will need to deliver more story points than were planned in future sprints to remain on schedule.
A question was asked:
Alan, how are the "defects", which are a mix of change requests and true defects that were not included in story points, accounted for?
Change requests are not defects and would be handled as a new or modified user story. If you change the user story then you need to re-size and re-estimate the effort.
Defects are where constructed code does not meet the business, stakeholder, or solution requirements. Defects that occur would be reviewed and classified as one of the following:
1. The defect is small. So small that you as a good developer considered the possibility of minor rework when you put together your PERT estimates. Therefore, your effort is covered under your original estimate.
2. The defect is large. Someone really missed the boat on developing the code because it does not meet the requirement(s). In this case a defect in Rally can be converted to a new user story which would then be added to the existing sprint backlog or put on the release or project backlog for future sprints. This will increase the size of the backlog and increase the scope of the project, which it should because there is now greater effort. This type of defect could increase the duration of the project.
In the case of both situations your effort needs to be tracked under an existing or new user story, which will then report up to the SPI.