Help with stories in Scrum

Question

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.

Answer 1

1) Estimating in Story Points.

A common criticism of story points is that they will mean different things to different teams. So yes, you are correct in your presumption.

Estimating in story points in my opinion is not only faster than estimating in developer days but will become more accurate over time. That is of course you get by the initial learning curve of estimating in these units.

Firstly, you need to recognize that story points are an estimate of effort...not complexity. You had mentioned this is what you were driving for but your team members need to understand that difference as well.

To combat the "what does 1 story point mean syndrome" take a story from a previous sprint that everybody on the team has a good understanding of. The story should have an an estimate of 2 assigned to it (assuming you are Fibonacci numbers, if not I would recommend looking into it). This is now your keystone!!! Frame it and take it to every single estimation meeting. Every estimate the team makes should use this keystone as a reference point.

This does two things for a scrum team:

• Your estimates will have an anchor, so that you can confidently say that from estimation meeting to estimation meeting your estimates will mean the same thing.
• You can now measure improvement. If your estimates are anchored then you can see if your team is getting faster / slower and your burn up/down charts will be that much more accurate.

It also will answer the question of what does one story point mean. It is any story that will take less effort than the keystone.

2) Breaking stories down into tasks

If you are breaking stories into developer tasks within an estimation meeting then you have found yourself more than likely a poorly written user story (most often to large in size). Kick the story from the sprint and break it down for the next estimation meeting. Leave the break down of story either to when it is picked up from the board and designed or if your team prefers at a design meeting.

No, developers do not need to break down a story into tasks to estimate it. Is it more effort than the keystone card? Smaller, the same? Do they understand the story after a brief discussion?

Answer those questions and move on! Estimation meetings should be quick. The scrum master on the team needs to ensure this discussion doesn't dive into the nitty gritty details of design!

3) Technical Stories

Stories should always be taken back to business value. If you're developing a story that has no business value than you should question why is it in your sprint? Again, this can be attributed to a poorly written story. Why does the developer need to write a MuleESB app? What benefit does it have on your project? The company? The foundation?

The only thing that should not have a story point on it (in my opinion) is a bug that was a result of a previously released iteration and you have found it on your board.

Writing Good User Stories As the PM (product owner scrum role) you need to be writing good user stories. The invest mnemonic is in my opinion one of the most fundamental aspects of writing good stories that often gets overlooked. INVEST in good user stories!

On the good user stories front, if you haven't read Mike Cohn's book I would highly recommend it: http://www.amazon.ca/User-Stories-Applied-Software-Development/dp/0321205685

Answer 2

1) Estimating in story points

Try estimating with T-Shirt sizes: Small, Medium, Large (S, M, L). Anything which is an Extra Large (XL) can be split up into smaller stories. You can then correlate these back into relative points - 1, 2 and 4 work well for me.

There are also alternatives to estimates. It might be worth looking at Lean / Kanban's measurements of Lead Time and Cycle Time, and definitely read Dan North's post on the perils of estimation.

2) Breaking stories into tasks

Have a think about why you break stories into tasks. Is it just to show progress? Or is it to allow the team to collaborate? Does it help the team to estimate the stories they're doing? When you understand the benefits that the tasks are providing, you'll have a better idea about the granularity you need. I also wrote a post about it recently which might help.

3) Technical Stories

The only reason this is confusing is because we refer to stories as "User Stories". They're not! Often stories aren't created for the benefit of the user - they're created for the benefit of some other stakeholder. For instance, think about adverts on a website or a CAPTCHA box.

Technical stories are also usually done for the benefit of some stakeholder in the project. Perhaps they're there for a security specialist, or for performance, or for maintainability going forward. If you can find the business benefit, you can phrase technical stories accordingly. I like to put the "so that" at the top:

In order to keep the site up under peak load
As the head of advertising
I want as many pages as possible to be cached.

In order to start the app in less than 10 seconds
As a user
I want the initial data load to be done asynchronously.

The fact that the advertising head and the user don't understand what it is they want is beside the point - their overall goals can easily be understood this way, and the business benefit is clear. I wrote a post about this too, with more examples of technical stories that you can look at.

Hope this helps.

Answer 3

Regarding Technical Stories, there will always be a need for these in Agile projects, such as R&D or architectural enhancements, etc. These are different from User Stories and are referred to as Spikes. Spikes are time-boxed but may not be add business values and may not be potentially shippable. Spikes are part of Sprints.

The problem I see is that you have mentioned, "most of our stories tend to be technical in nature". This could mean that your team has failed to identify and write good stories. My recommendation for the team would be to refresh the concept of "user story". Lets take your example, "As a developer, I need to be able to create a MuleESB app and integrate it into our build environment". First of all, "as a developer" is going against the Agile mindset. A good user story starts with the "target system user", such as, "As a portal admin, I want to ... so that I can ..." or "As a premium user, ..." or "As an accounts manager, ...".

Next, your client does not want a MuleESB app. So this can not be a user story. Lets say, client wants to see the historical data, present in legacy system, on the web application interface. To deliver this user story, technical team may have to create a MuleESB app so that data can be transferred from the legacy system to the web application. Think why do you need to create MuleESB app? for which user function? Creating MuleESB app could be a task of this user story.

Important part here is that the MuleESB app should be programmed to fetch the required data only, even though you know that more integration points will be required for other stories in future but do not implement those in this sprint. This is the "art of maximizing the amount of work not done".

Now, you have created a vertical thin slice of the required system in this particular user story.

Answer 4

I'll take a crack.

1) Estimating in Story Points.

Arbitrarily pick one story which everyone understands and give it a number. Say, 5. Use that as reference when estimating everything else.

2) Breaking stories down into tasks

Some things to try:

a. Hold a Product Backlog Refinement session in the previous sprint with the Product Owner and team to get clarity on the stories. This way you'll waste less time on arcane discussions in Sprint Planning.

b. Don't create tasks, or create as few as possible. Why do you need them? If your story is well understood, do you really need to invest the time in breaking them down further just so you could move something along the board? As long as you're running effective daily standups, and your stories are well written, you'll identify your blockers, which is really what the point of tasks is (hey, my task is stuck in 'in progress', something must be wrong!)

c. Detail the story, off-load the creation of tasks outside the sprint planning. Especially effective if you only have one person working on the story, that way they can organize themselves in private and stick stuff on the board later.

3) Technical Stories

This is the grunt work that every team has to do, the "setup" work that's needed before you can start adding features. There is nothing wrong with the story in your example. You could just rewrite it, as @Lunivore suggested, to reflect the business value. The real question is are you able to demo something? Even if it's a technical demo where you see database tables or see a message being passed through Mule. I'd say there is a way to do that, so you're good.

Answer 5

In many of the cases, it´s very difficult to shows that a technical US can add value to the business ! Most of us have the mindset that something that can't give some ROI to the company must be removed from the backlog. But if this spikes - as Jesse used to describe technical US - could aggregate some value to the team, and this value can let the team be more efective and do the things more quickly, than you are adding value to your company since you can be more productive and put more quality in what your team delivery.