Someone had an argument with me about something I mentioned about scrum at some place.. ( Ok I would call it a “discussion” :-)) I love when someone challenges me on something what I talk about..!
Ok the “conversation” I had is this;
I said the scrum project starts only when the Product backlog is ready !! Im sure Im correct.. Ken Schwaber said it better way than me.. (Obviously he should! )…“The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog “sounds clear..!
The point is that, in business, we position ourselves as a total solution provider in software. Specially in Outsourcing business where we are in to, the product owner becomes a role from the customer’s business manager or the product manager. Because the total understanding and the product vision is very difficult to be transferred to another person who is outside the geography boundaries as he has no much understanding about the target market. ( we could hire someone from the customer location as a consultant for sure, but its not a practical solution for every project we do )
We all know that Product owner is never a part of scrum team. Ok then, do we leave the product owner to create the product backlog in that case? Do we have product owners who has enough time and knowledge to do the groundwork which is required to come up with the product backlog?
I thought this would help many readers who are about this pre stage of scrum.
The point is Yes ! Scrum doesn’t stop the team getting involved with doing necessary mind mapping work, wire frames , use-cases and other background work to help the product owner to get the user stories of the product done.. But those tasks will not happen within the scrum project. In scrum project everything is time boxed. We have a planning meetings within defined time , we have tasks to be executed ( sprint) within defined time and we have a scrum day within a defined time. So we know exactly how time is taken for these specific user stories to be developed in scrum. However, the pre tasks such as helping the product owner to get the user stories ready can be done with the team involvement, and then the question is “when the team can get involved with the process”
It can happen at anytime, but the latest is the product backlog planning meeting . Then the question comes.. How long time is needed to come up with the user stories? I don’t think any Scrum guru can give an answer to that..( I learned during my CSM that there is an easy answer for all the difficult questions in scrum – the answer is “it depends”)
Actually the time needed to come up with user stories really depend on the knowledge of the product, availability of other stakeholders, business environment, and many other factors. I don’t think the time you spend to come up with Product A for 100 user stories will have any relationship to the time you need to come up with Product B :100 user stories. Otherwise there could be already set benchmarks in the industry for time to create user stories. Which is never the case.
Subscribe to:
Post Comments (Atom)
8 comments:
A Diagram is Worth a Thousand Words
http://www.agilemodeling.com/essays/barelyGoodEnough.html
OK! why did I post this here?
Rather! is this a comment for your post?
Yes.
Don't try to find answers from Waterfall for a scrum question.
There are many questions answered by XP. Scrum alone will help only to some extent. User scrum the manage the project and XP to get the work done by the team.
Thanks a lot Shafraz.. Its an interesting article..
In the same time I like to use more pics and diagrams in this blog instead long posts.. the problem is currently its not that easy .. It needs extra effort all the time .. and most the time when I finish writing the posts Ive already fallen a sleep.. :-)
User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax
Read more in: http://www.extremeprogramming.org/rules/userstories.html
Interesting text. You have a nice blog. Keep it up!
I am going through such pre scrum phase as of now. :) It is really difficult to define role of team prior to scrum. Specially, in large project, often customers has a long list of objectives and if you collect all the user stories it might take a very long time. It is difficult for even PO to prioritize at that level as user stories are not available yet so PO need to prioritize even user story collection.
Hi Kaushal,
Very interesting.. Definitely this is something we need to think serious.. I was thinking.. if we can get the Themes first and then prioritize the themes and get the user stories first for most prioritized themes as 1 product backlog that will help. Have you ever done that? Further doing user stories very little initially will have a problem in this type of a chart..
Check this link http://blogs.decadesoftware.com/hlarledge/2007/11/exploring-the-m.html
Btw sorry I didn’t catch up with you for some time.. I was quite everywhere lately.. Please share your experience with this sort of product backlog problem for a larger project when you progress. Very interesting to hear about it !
Hi, I liked your article and the discussion going on in comments is interesting. Bye.
i like to your nice blog.
Post a Comment