Estimating user stories at the start of the project so that the PM can determine a quote for the client

Question

Recently I have started to work on a team in a new project. Our company is attempting to run things in an Agile manner.

The project team consists of 4 developers each from different teams and with different business domain knowledge of the new project.

Our first get together involved going through a list of user stories and using Planning poker attempted to give estimates for the stories presented. However I really struggled with this process.

Here for a few things that I struggled with.

1. A-lot of the stories were UI driven and the complexity of it could depend on the complexity of the UI which we had no idea of. Hence I struggled to estimate appropriately.
2. The PM wanted us to estimate all the stories. However some of the stories had huge unknowns and questions which the PM couldn't answer.
3. Some of the stories involved knowledge about how we were going to implement the system from a code design point of view. We couldn't really agree on anything in particular as it involved some decisions from external people.
4. In our estimates there was no tester involved to add their input.

An example of a couple of the user stories looked like:

As an Account Manager / Field Office I want to to install the application locally so that I can use it when offline.

As a CRM Administrator I want to be able to store the xml files from the application into the company CRM system so that I can print branded reports.

Despite all of this, we still went through estimating using relative story points. The PM was then going to go away and cost up the project and estimate it time wise so she can do a quote for the company requiring the work.

My questions include:

1. As developers is it our responsibility to ensure we have enough information in order to estimate. If we have unanswered questions should we push back and require more.
2. Should you estimate all user stories at the start of a project?
3. Given our estimates what is the best way for the PM to determine the hours per point so that she can estimate a total cost? I believe typically we use the average time from a previous project however this project consists of 4 new developers.
4. Should we do UI mockups and design discussions during this process to help us better estimate?

Answer 1

If project is new and there is no previous experience then I suggest you use story points to estimate user stories.

A-lot of the stories were UI driven and the complexity of it could depend on the complexity of the UI which we had no idea of. Hence I struggled to estimate appropriately.

If complexity depends on UI then usage of story points is the best choice. Relative estimations is not as fragile as absolute ones.

The PM wanted us to estimate all the stories. However some of the stories had huge unknowns and questions which the PM couldn't answer.

For that stories you can either ask for clarifications or give raw estimations/guesstimate. It is up to you. If stories are really huge and not clear I suggest you ask PO to split them and participate your estimation meeting. I'm sure you'll get the fastest feedback then.

Should you estimate all user stories at the start of a project?

Estimated backlog is required for efficient product backlog management by Product Owner. It is a good practice to fill in and estimate the whole backlog when project starts in order to provide a high level estimation of the product. It is obvious that new stories will be added in the future anyway but it can provide a starting point.

Given our estimates what is the best way for the PM to determine the hours per point so that she can estimate a total cost? I believe typically we use the average time from a previous project however this project consists of 4 new developers.

Yes, experience from previous projects can be used. You can calculate an average amount of story-points per developer per sprint. Anyway, it is better to calculate an actual team's velocity after 2-3 sprints since "Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known."

Should we do UI mockups and design discussions during this process to help us better estimate?

If development team consider that UI mockups are needed for their development then there are no reasons to avoid them.

In our estimates there was no tester involved to add their input.

If you follow Scrum/Agile then there is no value in the increment without testing since it is a part of Software Development process. Every story requires acceptance testing. After several sprints you'll define the team's velocity - how many story points your team can finish within one sprint.

Answer 2

These are just some thoughts and experiences on UI driven projects.

3 months ago we have started a new project to completely re-develop the backbone of our 10 years old industrial automation products. We did many brainstorming meetings for the hardware, software, firmware etc aspects of the project. Then we decided to approach the project in a multi-team fashion.

The software part of the project did include a complete redesign of the whole UX area. So as the developers are still developing the base of the code we're working with a freelance UX expert who coordinates us with his expertise. We created personas, laid out scenarios and use cases, designed mockups and wireframes, and nowadays are starting to select the proper technology based on the requirements which emerged from all these studies and the prototypes. We are just at the beginning of the UX part of the project. There will be much more steps along the way.

As you can see and I think already know, UI is not a one step/one time issue in a product's design lifecycle, instead its the main driver of the backbone. You should warn your PM on the consequences of omitting this phase of the project. The contrary decision would lead the project into chaos in the long term.

Answer 3

I can see several red flags here:

1) Your stories as posted have no acceptance criteria. How is the customer/PM going to be able to tell whether something is complete besides personal whim?

2) Your stories as posted have no behavior in them... they talk about the goals of the system, but have no information about how it behaves based on what the user is doing.

3) You also made no mention of "elaboration". You don't do estimation until the story is elaborated enough for you to make a reasonable estimate. Do you feel that you could reasonably implement these stories as given? If not, then it isn't ready to go into the backlog, and isn't ready do be estimated. From what you've posted, the PM is treating the backlog like a wishlist, not a priority queue of "shovel-ready" tasks.

Also this:

As an Account Manager / Field Office I want to to install the application locally so that I can use it when offline.

Something tells me that's an epic or story arc, and should be split into multiple, independently implementable stories.

Answer 4

I recently wrapped up a project that had a similar start. She needs the quote, and to build the quote, she needs your estimates. But for you to estimate, you need a level of detail that isn't always possible at this phase. It's a vicious cycle!

Our approach was to associate as many assumptions as we could drum up when putting together the estimate for each piece of functionality, and then put a risk value on those assumptions. When she's presenting her quote, she can then somewhat confidently tell the client: here is our cost range estimate, which is based on these assumptions that we estimate to have this level of risk involved.

Hopefully that helps a bit, and best of luck!

Answer 5

Recently I had similar situation

• new team without QA at the beggining
• new customer that work with domain unknown for us
• a lot of legacy code on which we had to develop

Customer asked us to provide planning with documentation consists of

• delivery date for the project
• how the provided requirements influences over current product we had to change
• technical information what code changes are required

We wanted to run the team in Agile manner (Scrum), so we decided first to find as many User Stories as we can - we spent on it several days discussing and analysing requirements. Then we found out that even if we estimate user stories in points, we won't be able to calculate it into mandays, so we didn't do that. Having user stories, our understanding of the system was much better so the work we did wasn't unnecessary. Eventually we started analysing technical aspects of the project and building WBS with technical tasks. We used PERT (http://pl.wikipedia.org/wiki/PERT) as an estimation technique (there are many others but this seems to be the easiest and quickest to implement).

Thanks to this approach we prepared two offers, pessimistic and most likely (from PERT). Cone of uncertainty was used as a one of the arguments why we cannot be sure about delivery costs and date. Customer accepted that and didn't try to undermine it.

What was next? Customer suspended the project because of other reasons and gave us another, smaller project that gave us time to introduce better into the domain. The team is much experienced now:

• we know the domain
• legacy code is understandable
• we work in Scrum so our 'agile experience' is also much higher

One of the summaries from retrospective about planning we did is that happily customer hadn't decided to start this project, because even pessimistic version was wrong:

• lack of QA at the beginning is bad - we tried to think about testing the software, but from "developer point of view" which is limited
• legacy code is not so easy to developed as we thought
• there was no Product Owner that can answer for all our questions, so many assumptions we did (because we had to) were wrong