Story: As a business analyst I should able to see 4 new columns in the report
Estimated: 3 story points 1 story point is 20 hours == 60 hours.
So this story would take 2 weeks , 1 sprint to complete this one story for one person.
Questions are: 1] is it the right way to estimate a story? 2] can a single story have multiple people working on it? 3] Each sub-task in this story probably needs to be 6 hours per day as per guidelines in JIRA or other Agile tools. As long as the story completes in 60 hours, does it matter how many hours we assign to each sub-task? 4] In this type of estimation, this story may show pending or yet complete status for a long time in Burndown chart, is this correct?
What is the best way to structure this story for maximum benefit to customer?
Story points are not measurements of time, so no. Story points have an approximate correlation with time when we have a consistent team in a consistent context. Then the correlation is close enough that we can say that a team completes some number of story points in a period of time like 2 weeks. That is as specific as we can get. Any individual backlog item will vary too significantly to make a points-to-time comparison. This may seem frustrating, but it was specifically designed to subvert this type of time estimation.
Yes, absolutely. In fact, most teams in most contexts will find that multiple people working on an item in the backlog is the most effective way to work.
That's a pretty good rule of thumb. Think of it more like "experience has shown that...". Past that, there are no real rules around sub-tasks. They are there for the team or organize their own work. Make them as big or small as the team finds useful. You don't even have to use them at all. Also, to the previous point, it doesn't actually matter what the estimates or actuals for the sub-tasks add up to and there is nothing that says you even need to estimate them. Most teams I've worked in find estimating sub-tasks to be wasteful.
Yes, you are correct. A backlog item that takes multiple days to complete will not burndown until it is all done. That is intentional. This comes from a long history of work being "almost done" for a large percentage of time that it is in progress. By looking at done as a binary state, it creates incentive to finish items before starting others.
You also ask about structure. User Stories are a way of expressing the need of a user. In the example you give, I would assume that a Business Analyst is an end-user. I would also assume that this User Story is strictly describing work to format existing data. A best practice is to also add a "so that" to the end like "so that I can see trends over the past 4 quarters". It's important to keep in mind that User Stories are not a specification. They are a narrative that the team draws from to design an experience in their product. If that isn't what you're looking for, Scrum does not require you to use User Stories.