Our company is trying to follow Agile methodologies when it comes to estimating and prioritizing any new development work. The reading I've done makes this concept appear great so we are trying to give it a good crack at making it work for us and hence help with providing a better solution at the end of the day for our customer.
A problem I have had recently is the position of UI design during the estimation of User stories. We kicked off a new project discussing what was required from a functional point of view and getting a set of user stories written down to be verified by the user. Our BA then asked us to estimate these stories.
I went, hang on. Many of these stories might vary depending on the complexity of the UI design. However the BA wasn't ready to discuss UI just yet as she needed estimates so she could plan the sprints and get a costing for the project.
So my main question is:
Where does UI design fit into the process between writing user stories
and estimation. Or, should it even fit in and just be a part of the
development work?
Secondary question
How does agile fit into fixed price quotes for new work (based on your
estimations on the entire user stories set), and how then do you
ensure you deliver what you said as far as the user stories go against
the quote given i.e. a story is bigger than you thought so blows out
My concerns around our process:
- I can't estimate accurately enough at this stage of the process as some elements are missing i.e. UI. It's a new project for a new client so heading into some uncertain waters.
- Some features are just too unknown to estimate (Do I need to just delve deeper into the murkiness to clear the waters to remove the unknowns??)
BA needs (as expressed to me)
- Wants to have estimates so they can determine how many sprints this project will take
- Wants to have estimates so they can determine the scope and cost of the project so that they can give it to the customer as a quote.
Best Answer
UI design is no different than architecture or coding or testing -- it's part of the scrum process. Some say that in an ideal world the team will do all of that in a sprint -- but only enough UI design for that sprint. Others are more pragmatic and say it can't be done, and will do design in one sprint and coding and testing in another, or design and coding in one and testing in another.
A common pattern is to do design work / UI stories in one sprint and code in the next. After all, if you don't know what the UI is like there's no way you can estimate how much effort will be involved in coding. Consider the difference in the home page for google.com vs bing.com -- both have the same primary function, but bing.com has a considerably more elaborate UI design.
That being said, estimates are just that: estimates. Nothing in scrum requires that they are accurate only that they are consistent over time. Whether you estimate a story as a 5 or a 13 doesn't matter as long as similar stories are estimated the same way from sprint to sprint.
So, do what the team thinks is right -- do a UI story before doing the development, or do them together. If the PO says they have to be done at the same time, make sure you factor into your estimates all of the uncertainty. Do your best to estimate, knowing it will be wrong. Learn from that in your retrospective and talk about what worked and what didn't. Then, adjust your procedures going forward.
Above all, don't expect the estimates for the first half-dozen sprints or so to be the least bit accurate. Over time, however, regardless of the strategy you should start to do approximately the same number of points each sprint, which the PO can then use to predict how many stories you can do in a sprint.