Month: May 2016

4 Steps to Get the Real Error Message from SharePoint 2013 Log Files

Maria Grazia MerloLeave a comment

In this post I’m going to show you how to find the details of an error in the SharePoint log files.

Scenario

Sorry, something went wrong. An unexpected error has occurred.

Many of us have seen this non-informative message before, wondering what really happened.

FindError_Message

We need a way to get the real SharePoint exception to investigate the problem.

Solution

We can do that by using the SharePoint “Unified Logging System” (ULS).

SharePoint saves the details of errors and other diagnostic information in a log file on the server where the error happened.

Steps

1. Get Correlation ID

The first step is to note the Correlation ID.
You can directly copy it from the browser in the SharePoint error page.

FindError_CorrelationID

2. Get and Open ULS Viewer

You can open log files with Notepad or your text editor of choice.

However Microsoft has a tool called ULSViewer that can help you find your error more easily with the use of filters.

FindError_ULSViewer

3. Open Log File

Now you need to find and open the specific log file that contains your error.

To open a log file click on File -> Open From -> File.

FindError_OpenFile

By default SharePoint log files are stored in the SharePoint hive in the LOGS folder:

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS

FindError_LogFolderHowever note that this path can be changed in SharePoint Central Administration.

SharePoint log files are named with the format “SERVERNAME-YYYYMMDD-HHMM.txt” where SERVERNAME is the server’s computer name, YYYYMMDD is the current date and HHMM is the time the log was started using a 24-hour clock.

In single server farms open the log from the day and time which the error happened.

In multi-server farms you’ll need to go to the specific server where the error happened to locate the log. If it’s not immediately obvious where the error happened you’ll need to check every server in the farm.

FindError_LoadedLogFile

4. Filter Log Entries

To find your error you will need to filter the log entries by Correlation ID and Level.

To do this click on Edit -> Modify Filter.

FindError_ModifyFilter

Then set the following values in the Filter By dialog.

Correlation ID filter:

Field: Correlation
Operation: Equals
Value: The Correlation ID you copied from the SharePoint Error message
And/Or: And

Level filter:

Field: Level
Operation: Equals
Value: Unexpected

FindError_Filters

Click OK and ULSViewer will show only the events that have the Correlation ID and Level specified.

FindError_FilteredLogEntries

Conclusion

Now we can finally see the real error!

If you double click on the log entry, a window will open to show all the error details so that you can begin your investigation.

FindError_ErrorDetails

References

Jason Warren

How to Estimate User Stories

Maria Grazia MerloLeave a comment

In this post I’m going to show you the process and techniques to effectively estimate user stories.

Scenario

In our project we are using an iterative process in conjunction with user stories and we need, or are asked, to provide an estimate of how long the project will take.

EstimatingStories_QuestionMark

Ideal Estimation

The best approach for estimating user stories would be one that:

  • Allows us to change our mind whenever we have new information about a
    story
  • Works for both big and small stories
  • Doesn’t take a lot of time
  • Provides useful information about our progress and the work remaining
  • Is tolerant of imprecision in the estimates

Story Points

EstimatingStories_StoryPoints

An approach that satisfies each of these goals is to estimate in Story Points.

Story Points are relative estimates of the complexity, effort or duration of a story.

A nice feature of story points is that each team defines them as they see fit.
Story points can be entirely nebulous units or ideal time units like “ideal day” or”ideal week”.
Of course, as we’ll eventually need to convert estimates into time, starting with ideal time makes that conversion a little simpler than starting with an entirely nebulous unit.

What to Include

When programmers estimate a story, they should include everything they’ll need to do to complete it.

They need to factor in such things as testing their code, talking to the customer, perhaps helping the customer plan or automate acceptance tests, and so on.

Estimate as a Team

Story estimates need to be owned collectively by the team for two main reasons:

  1. Since the team doesn’t yet know who will work on a story, ownership of the story cannot be more precisely assigned than to the team collectively
  2. Estimates derived by the team, rather than a single individual, are probably more useful and accurate

EstimatingStories_Team

Process

To estimate user stories as a team:

  1. Implement a baseline story
  2. Compare with the baseline story and other user stories
  3. Split in tasks

From Story Points to Expected Duration

EstimatingStories_Calendar

Now we need a way to convert story points into a predicted duration for the project.
How to do that?

The answer is to use team velocity.

Velocity represents the amount of work that gets done by the team in an iteration

Once we know a team’s velocity, we can use it to turn ideal days into calendar days.
For example, if we estimate our project at 100 ideal days, then with a velocity of 25 we can estimate that it will take 100 / 25 = 4 iterations to complete the project.

It is often necessary to estimate a team’s initial velocity.
To do that you can:

  • Use historical values
  • Run an initial iteration and use the velocity of that iteration
  • Take a guess

References

Mike Cohn