The company I work for has recently greenlit a large project to completely rewrite our software product. As PM, I have championed using Scrum on the project and the company have been very supportive of the process.
Howevever this is the first time I, or any of the developers, have been involved on a Scrum project. We've are in the middle of our fourth sprint now, but I have a ton of questions (I'll just stick to my top three for now!)
1) Estimating in Story Points.
This is probably the number one thing we struggle with during our planning sessions. At first I got the team to estimate in Ideal Man Days since the concept of Story Points was too alien. However, from the third sprint onwards I've tried to shepherd them into using Story Points (based on effort not time).
Even after two sprints using Story Points I still get the question, "what does one story point mean?". Despite the hours of online research I've put in, I myself feel unsure how I should answer this question. I tend to fall back to the Ideal Man Day since it's the easiest thing for everyone to understand, but I would really like to give a definitive answer to the team that isn't fluffy or vague. Unfortunately, almost every explanation I've come across on the web suffers from this. Am I to presume that a Story Point means different things to different teams?
2) Breaking stories down into tasks
My question here is how much of the story should be broken down into tasks during the planning session? We have been generating an average of four tasks per story, but some of these could be broken down even further. While I understand that too many tasks is a bad thing, I get concerned when I see the same task in progress for more than a day or two. So I'm a little torn as to how granular the tasks should be.
Also, I've found breaking down a story too much during the planning session was digressing into a design discussion. When I raised this with the team they countered that they needed to fully explore the story in order to generate tasks and help with with the estimatation.
3) Technical Stories
From what I've studied, stories should cover a feature of the product that adds value to the business. However, since we are at the beginning of the project, most of our stories tend to be techincal in nature. An recent example of this is, "As a developer, I need to be able to create a MuleESB app and integrate it into our build environment". This kind of story adds no value from a business point of view, but is crucial in laying the foundation for the work to come.
My question is whether it is ok to have techincal stories and assign them points. I am concerned that if I don't, then the team's velocity will be very low and it will look like they've not been doing very much; at least in the early phases of the project.