The plan is to create user stories that the development team can use in their agile process with 1 month sprints.
Some remarks:
1 month Sprints is IMHO too long, especially for an adoption and I prefer to use 2 to 3 weeks Sprints. During an adoption, shorter feedback loops give you the opportunity to inspect and adapt more frequently and since you are experimenting, this is in general appreciated.
I don't really understand what is so hybrid in your requirements gathering session as long as the goal is not to create the "final" list of fine grained Product Backlog Items in one shot (a backlog has typically a pyramidal structure with fine grained items at the top - for the upcoming iterations - and coarse grained items at the bottom). Having story-writing workshops ahead each iterations is a common practice.
PS: While I respect Péter's opinion, I have a slightly different one. I consider Scrum (we're talking about Scrum, right?) as a minimal and finely balanced framework and recommend to stick as close as possible to doing Scrum by the book. Sure, the goal is not to be Scrum but to deliver working product increments. But unless you have someone experienced with Scrum in the team, you (as organization) are not really qualified1 to alter the framework (and to understand the impacts) and might not get all benefits. Scrum is flexible, there aren't two similar Scrum implementations. But dropping a part of the framework is not the same as being flexible.
1 I often introduce the Shu Ha Ri progression model (that roughly means learn - detach - transcend) for agile adoption. From the C2 wiki:
As the beginner starts to learn, Shu gives them structure. It forces them to adhere to the basic principles (...). Since the beginner knows very little, they can only progress by slavishly adhering to these principles (...).
As the beginner gains experience, they naturally will wonder why?, how?, is there something better? Ha... the separation (much softer word than break) is the experimentation done around the principles... first straying only a little and then more and more as these ideas are tried against the reality of the world.
As the experiments of the Ha stage continue, bit by bit, the successes are incorporated into daily practice... we look for opportunities and use the patterns we have learned and tried out that closely fit those opportunities. This Ha/Ri stage is what makes an art the 'property' of the practitioner rather than the teacher or the community. Eventually, you are able to function freely and wisely.
I'm certainly not saying that one must stay at the Shu phase (the goal is beyond the first level), what I'm saying is that learning new ways of working takes time, don't ignore practice. As Ron Jeffries once said "They're called practices for a reason... You have to have done them. Practice makes perfect."
Update: (answering a comment)
One of the decisions we would like to take is the role of each person in the 'Product Owner' team.
Just to be clear: there should be only ONE Product Owner. He can of course work with a team but, still, there should be a single authoritative voice for the team. If I rephrase, there is no Product Owner Team.
For ex: What would the role of a technical person be?
Well, for me the technical person has no role to play in this team (unless he is there to train or support people at writing stories but the ScrumMaster should typically do that). Writing stories means capturing the essence of business oriented features, there is no real need for a technical point of view at this stage. Technical complexity (or even feasibility) will be included later in the estimation.
It seems to me that the end result of the requirements phase would be user stories that the developers will use in the iterations. Will the technical person be estimating the tasks? Traditionally, we've had the programmers estimate their own tasks
People doing the work should estimate the work (you can't expect a team to commit on something if someone else estimate the work for the team). In other words, the team should estimate stories. On top of that, experience shows that 1. collective estimations works better than individual estimation 2. we are better at doing relative estimations. So my recommendation would be to estimate the size and complexity of stories relatively using story points/t-shirt size/unit-less points and to do collective estimation during planning poker sessions. This worked very well every where I used this.
One of my colleagues (I work for a company which consults in agile working) has written several blogs about this separation between the requirements gathering and the development process. He describes how this can work very well in practice.
在我们当前的项目中，我们的许多用户仍然分布在全球大部分地区。然而，至少我们的 IT 管理层对软件开发和敏捷流程更加了解。我们开发的是一个大型遗留系统，几年前该系统的状况相当糟糕 - 因此维护和稳定是我们日常工作的很大一部分，而新需求平均花费的时间不到我们一半的时间。不过，当我们有一个项目时，我们通常会召开初步估算会议，尝试对这个项目需要多少人日进行粗略估算。然后，我们的业务分析师与利益相关者一起制定出越来越多的细节，而我们的团队则致力于填写技术细节。
So far I have had experience with hybrid models only :-) None of the agile projects I have worked on so far implemented any Agile methodology strictly by the book. You needn't either.
The point is, any methodology is just a starting point / a collection of ideas you can use to work out your own process, tailor made to the specific project, team and circumstances.
Start with a process which looks good to you, then see how it works in practice. Keep regular retrospectives at the end of each iteration to assess how things are going, what worked in the last iteration and what didn't, and how could you improve things further. Then implement the most important ideas in the next iteration. In other words, develop the development process itself in an agile way :-)
Update: anecdotes about the requirement process
As I write this, I realize you may not got much useful info out of it... but at least it shows you that projects and processes vary a lot.
In one project, we had a fairly strict Scrum process, with a product backlog, although we didn't have a real customer: the product was new, and the prospective users didn't yet know it existed. Also it was a fairly specific and standardized domain where our company had a lot of experience. At the time I was part of the team (this was before the first release) we didn't really have much formal requirements gathering, because much of the key requirements were imposed on us by a standard. On top of that, we had some of our own ideas how to make the product stand out of the crowd.
In another project, we loosely had a Scrum process, but our sponsors and users did not really know about it, so we were struggling quite a bit. The "requirements gathering" was rather informal in that the product was huge and different people / subteams were assigned to different areas, working fairly independent of each other. Each subteam had their own contact(s) to discuss the requirements with, and the contacts were geographically separated - we rarely saw any of them face to face, so most of the communication happened via email, using lengthy Word docs. To top it off, we had a team of domain experts, who were often in wild disagreement with the users regarding the concrete requirements, however they were not very communicative. So the requirement process often consisted of reading lengthy documents containing obscure mathematical stuff, then other lengthy documents containing GUI requirements, then trying to figure out how to bring the two together... then discussing the requirements with the domain expert who briefly announced that it was a piece of sh*t, and we tried to tease some more useful and concrete improvement ideas out of him... then rewriting the requirements doc according to our latest understanding and the expert's comments, and sending it back to our contact person... then repeat from square 1.
In our current project, we again have many users scattered around a large part of the globe. However, at least our IT management is more knowledgeable about SW development and agile processes. We work on a large legacy system, which was in a pretty bad shape a couple of years ago - so maintenance and stabilization is a large part of our day to day work, and new requirements take less than half of our time on average. When we have one, though, we usually have preliminary estimation meetings where we try to come up with a crude estimate on how many person-days this project going to take. Then later our business analyst works out more and more details with the stakeholders, and our team works on filling out the technical details.
It seems to me if you label business analyst, subject matter experts, technical person and a user interface person as "the product owner" team, you really haven't deviated from "pure" agile.
That said, "pure" agile is somewhat of a misnomer because most agile advocates will tell you that the #1 or #2 selling point is its ability to adapt to the business processes and corporate culture of your existing organization.
The critical success factor might be having that product owner team, and all stakeholders really, invest in participating in some of your dev team's agile processes (showing up for demos, being accessible for questions during the sprint, etc).
Edit:
This quote from Wikipedia documents the very simple role of the Product Owner:
The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog.
Scrum isn't meant to enforce processes on how the Product Owner gets their job done. It's only the interface between the Product Owner and the Team (sprint planning and sprint review) that Scrum tries to outline.
Could we call this, "Building the back log," as that is really what this is, to my mind? The idea is to get those top priority pieces and then work from there. I have seen a few different Agile processes and some worked better than others but the key is how well is the buy-in from those involved in the process.
I'd also agree that 1 month is too long for a sprint. 2 week sprints seem about right to my mind though I have seen slightly longer and shorter sprints that also work. Another question is how big is the team and projects that are being done as stuff that may take years may not be easily done. I say this as someone that survived a project that lasted over a year and many sprints and demos later finally finished the project successfully.
I'd likely consider the technical person being the one that has to keep an eye on the big picture and understand what may be reasonable to do and what is unreasonable to do,e.g. having the system read my mind to know what I want done before I wake up in the morning without my having to write out anything other than simply thinking it would be unreasonable. Don't forget that the stories will develop into more cards as the stories are just a high-level view of what the end result is, which usually doesn't cover how easy is it, how much time will it take and a few other aspects.
For the sprints themselves, developers should estimate how long it takes to do various tasks. Determining the priority of stories though isn't part of what the developers do though. The requirements gathering session could also be seen as building a project charter so that there is a timeframe for the project as a whole, objectives and other high-level details that should be stated at the beginning.
发布评论
评论（5）
一些评论：
1 个月的 Sprint 恕我直言太长了，尤其是对于采用而言，我更喜欢使用 2 到 3 周的 Sprint。在采用过程中，较短的反馈循环让您有机会更频繁地检查和适应，并且由于您正在进行试验，因此通常会赞赏这一点。
只要目标不是一次性创建细粒度产品待办事项列表项的“最终”列表（待办事项通常具有金字塔结构，细粒度的项目位于顶部 - 用于即将到来的迭代 - 粗粒度的项目位于底部）。在每次迭代之前举办故事编写研讨会是一种常见的做法。
PS：虽然我尊重 Péter 的观点，但我的观点略有不同。我认为 Scrum（我们正在谈论 Scrum，对吧？）是一个最小且精细平衡的框架，并建议尽可能遵循书本上的 Scrum 做法。当然，我们的目标不是成为 Scrum，而是交付可工作的产品增量。但是，除非您的团队中有 Scrum 经验丰富的人员，否则您（作为组织）并没有真正的资格1来更改框架（并了解其影响），并且可能无法获得所有好处。 Scrum 很灵活，不存在两种类似的 Scrum 实现。但放弃框架的一部分并不等于灵活。
1 我经常介绍Shu Ha Ri 敏捷采用的进展模型（大致意味着学习 - 分离 - 超越）。来自 C2 维基：
我当然不是说必须停留在术阶段（目标是超越第一级），我的意思是学习新的工作方式需要时间，不要忽视练习。正如罗恩·杰弗里斯（Ron Jeffries）曾经说过的“它们被称为练习是有原因的......你必须完成它们。熟能生巧。”
更新：（回答评论）
需要明确的是：应该只有一个产品负责人。他当然可以与团队合作，但团队仍然应该有一个权威的声音。如果我换个说法，就不存在产品负责人团队。
嗯，对我来说，技术人员在这个团队中没有任何作用（除非他在那里培训或支持人们编写故事，但 ScrumMaster 通常应该这样做）。写故事意味着捕捉面向业务的本质特征，现阶段并不需要技术角度。技术复杂性（甚至可行性）将在稍后的估算中包括在内。
从事工作的人员应该估算工作（如果其他人估算团队的工作，你就不能指望团队会致力于某件事）。换句话说，团队应该评估故事。最重要的是，经验表明 1. 集体估计比个人估计效果更好 2. 我们更擅长进行相对估计。因此，我的建议是相对使用故事点/T 恤尺寸/无单位点来估计故事的大小和复杂性，并在 规划扑克 会议。在我使用它的每个地方，这都非常有效。
Some remarks:
1 month Sprints is IMHO too long, especially for an adoption and I prefer to use 2 to 3 weeks Sprints. During an adoption, shorter feedback loops give you the opportunity to inspect and adapt more frequently and since you are experimenting, this is in general appreciated.
I don't really understand what is so hybrid in your requirements gathering session as long as the goal is not to create the "final" list of fine grained Product Backlog Items in one shot (a backlog has typically a pyramidal structure with fine grained items at the top - for the upcoming iterations - and coarse grained items at the bottom). Having story-writing workshops ahead each iterations is a common practice.
PS: While I respect Péter's opinion, I have a slightly different one. I consider Scrum (we're talking about Scrum, right?) as a minimal and finely balanced framework and recommend to stick as close as possible to doing Scrum by the book. Sure, the goal is not to be Scrum but to deliver working product increments. But unless you have someone experienced with Scrum in the team, you (as organization) are not really qualified1 to alter the framework (and to understand the impacts) and might not get all benefits. Scrum is flexible, there aren't two similar Scrum implementations. But dropping a part of the framework is not the same as being flexible.
1 I often introduce the Shu Ha Ri progression model (that roughly means learn - detach - transcend) for agile adoption. From the C2 wiki:
I'm certainly not saying that one must stay at the Shu phase (the goal is beyond the first level), what I'm saying is that learning new ways of working takes time, don't ignore practice. As Ron Jeffries once said "They're called practices for a reason... You have to have done them. Practice makes perfect."
Update: (answering a comment)
Just to be clear: there should be only ONE Product Owner. He can of course work with a team but, still, there should be a single authoritative voice for the team. If I rephrase, there is no Product Owner Team.
Well, for me the technical person has no role to play in this team (unless he is there to train or support people at writing stories but the ScrumMaster should typically do that). Writing stories means capturing the essence of business oriented features, there is no real need for a technical point of view at this stage. Technical complexity (or even feasibility) will be included later in the estimation.
People doing the work should estimate the work (you can't expect a team to commit on something if someone else estimate the work for the team). In other words, the team should estimate stories. On top of that, experience shows that 1. collective estimations works better than individual estimation 2. we are better at doing relative estimations. So my recommendation would be to estimate the size and complexity of stories relatively using story points/t-shirt size/unit-less points and to do collective estimation during planning poker sessions. This worked very well every where I used this.
我的一位同事（我在一家提供敏捷工作咨询的公司工作）写了几篇关于需求收集和开发过程之间分离的博客。他描述了如何在实践中很好地发挥作用。
One of my colleagues (I work for a company which consults in agile working) has written several blogs about this separation between the requirements gathering and the development process. He describes how this can work very well in practice.
到目前为止，我只拥有混合模型的经验:-) 到目前为止，我参与过的敏捷项目都没有严格按照书本实施任何敏捷方法。你也不需要。
关键是，任何方法都只是一个起点/想法的集合，您可以使用它来制定自己的流程，根据特定的项目、团队和情况量身定制。
从您认为不错的流程开始，然后看看它在实践中如何运作。在每次迭代结束时定期进行回顾，以评估事情的进展情况、上一次迭代中哪些有效、哪些无效，以及如何进一步改进。然后在下一次迭代中实现最重要的想法。换句话说，以敏捷的方式开发开发过程本身:-)
更新：有关需求过程的轶事
当我写这篇文章时，我意识到您可能没有从中获得太多有用的信息......但至少它向您展示了项目和流程差异很大。
在一个项目中，我们有一个相当严格的 Scrum 流程，有产品积压，尽管我们没有真正的客户：产品是新的，潜在用户还不知道它的存在。此外，这是一个相当具体和标准化的领域，我们公司在其中拥有丰富的经验。当时我是团队的一员（这是在第一个版本之前），我们实际上没有收集太多正式的需求，因为许多关键需求都是由标准强加给我们的。最重要的是，我们有一些自己的想法，如何使产品脱颖而出。
在另一个项目中，我们松散地有一个 Scrum 流程，但我们的发起人和用户并不真正了解它，所以我们遇到了很大的困难。 “需求收集”相当非正式，因为产品很大，不同的人/子团队被分配到不同的领域，彼此相当独立地工作。每个子团队都有自己的联系人来讨论需求，并且这些联系人在地理位置上是分开的 - 我们很少见到他们中的任何一个，因此大多数沟通都是通过电子邮件进行的，使用冗长的 Word 文档。最重要的是，我们有一个领域专家团队，他们经常与用户在具体需求方面存在巨大分歧，但他们的沟通能力并不强。因此，需求过程通常包括阅读包含晦涩数学内容的冗长文档，然后阅读其他包含 GUI 需求的冗长文档，然后尝试找出如何将两者结合在一起......然后与领域专家讨论需求，后者简要宣布了这一点真是一坨屎，我们试图从他身上找出一些更有用、更具体的改进想法……然后根据我们最新的理解和专家的意见重写需求文档，并发回给我们的联系人。 ..然后从方块 1 开始重复。
在我们当前的项目中，我们的许多用户仍然分布在全球大部分地区。然而，至少我们的 IT 管理层对软件开发和敏捷流程更加了解。我们开发的是一个大型遗留系统，几年前该系统的状况相当糟糕 - 因此维护和稳定是我们日常工作的很大一部分，而新需求平均花费的时间不到我们一半的时间。不过，当我们有一个项目时，我们通常会召开初步估算会议，尝试对这个项目需要多少人日进行粗略估算。然后，我们的业务分析师与利益相关者一起制定出越来越多的细节，而我们的团队则致力于填写技术细节。
So far I have had experience with hybrid models only :-) None of the agile projects I have worked on so far implemented any Agile methodology strictly by the book. You needn't either.
The point is, any methodology is just a starting point / a collection of ideas you can use to work out your own process, tailor made to the specific project, team and circumstances.
Start with a process which looks good to you, then see how it works in practice. Keep regular retrospectives at the end of each iteration to assess how things are going, what worked in the last iteration and what didn't, and how could you improve things further. Then implement the most important ideas in the next iteration. In other words, develop the development process itself in an agile way :-)
Update: anecdotes about the requirement process
As I write this, I realize you may not got much useful info out of it... but at least it shows you that projects and processes vary a lot.
In one project, we had a fairly strict Scrum process, with a product backlog, although we didn't have a real customer: the product was new, and the prospective users didn't yet know it existed. Also it was a fairly specific and standardized domain where our company had a lot of experience. At the time I was part of the team (this was before the first release) we didn't really have much formal requirements gathering, because much of the key requirements were imposed on us by a standard. On top of that, we had some of our own ideas how to make the product stand out of the crowd.
In another project, we loosely had a Scrum process, but our sponsors and users did not really know about it, so we were struggling quite a bit. The "requirements gathering" was rather informal in that the product was huge and different people / subteams were assigned to different areas, working fairly independent of each other. Each subteam had their own contact(s) to discuss the requirements with, and the contacts were geographically separated - we rarely saw any of them face to face, so most of the communication happened via email, using lengthy Word docs. To top it off, we had a team of domain experts, who were often in wild disagreement with the users regarding the concrete requirements, however they were not very communicative. So the requirement process often consisted of reading lengthy documents containing obscure mathematical stuff, then other lengthy documents containing GUI requirements, then trying to figure out how to bring the two together... then discussing the requirements with the domain expert who briefly announced that it was a piece of sh*t, and we tried to tease some more useful and concrete improvement ideas out of him... then rewriting the requirements doc according to our latest understanding and the expert's comments, and sending it back to our contact person... then repeat from square 1.
In our current project, we again have many users scattered around a large part of the globe. However, at least our IT management is more knowledgeable about SW development and agile processes. We work on a large legacy system, which was in a pretty bad shape a couple of years ago - so maintenance and stabilization is a large part of our day to day work, and new requirements take less than half of our time on average. When we have one, though, we usually have preliminary estimation meetings where we try to come up with a crude estimate on how many person-days this project going to take. Then later our business analyst works out more and more details with the stakeholders, and our team works on filling out the technical details.
在我看来，如果您将业务分析师、主题专家、技术人员和用户界面人员标记为“产品所有者”团队，那么您确实没有偏离“纯粹”敏捷。
也就是说，“纯粹的”敏捷有点用词不当，因为大多数敏捷倡导者会告诉您，第一或第二卖点是它适应现有组织的业务流程和企业文化的能力。
关键的成功因素可能是让产品所有者团队和所有利益相关者真正投资参与开发团队的一些敏捷流程（参加演示、在冲刺期间可以回答问题等）。
编辑：
这句话来自维基百科记录了非常简单的角色产品负责人：
Scrum 并不是要强制执行产品负责人如何完成工作的流程。 Scrum 试图概述的只是产品负责人和团队（冲刺计划和冲刺评审）之间的接口。
It seems to me if you label
business analyst, subject matter experts, technical person and a user interface personas "the product owner" team, you really haven't deviated from "pure" agile.That said, "pure" agile is somewhat of a misnomer because most agile advocates will tell you that the #1 or #2 selling point is its ability to adapt to the business processes and corporate culture of your existing organization.
The critical success factor might be having that product owner team, and all stakeholders really, invest in participating in some of your dev team's agile processes (showing up for demos, being accessible for questions during the sprint, etc).
Edit:
This quote from Wikipedia documents the very simple role of the Product Owner:
Scrum isn't meant to enforce processes on how the Product Owner gets their job done. It's only the interface between the Product Owner and the Team (sprint planning and sprint review) that Scrum tries to outline.
我们可以称之为“构建待办日志”吗？在我看来，这就是真正的事情？我们的想法是获得那些最优先的部分，然后从那里开始工作。我见过一些不同的敏捷流程，其中一些比其他流程效果更好，但关键是参与该流程的人员的支持程度如何。
我也同意 1 个月对于冲刺来说太长了。在我看来，两周的冲刺似乎是正确的，尽管我见过稍长和稍短的冲刺也有效。另一个问题是团队有多大，而那些可能需要数年时间才能完成的项目可能并不容易完成。我这样说是因为我是一个在持续了一年多的项目中幸存下来的人，经过多次冲刺和演示，最终成功完成了该项目。
我可能会认为技术人员必须关注大局并了解什么是合理的做法以及什么是不合理的做法，例如让系统读懂我的想法以知道我之前想要做什么我早上醒来时不需要写下任何东西，只是觉得这是不合理的。不要忘记，故事会发展成更多的卡片，因为故事只是最终结果的高级视图，通常不包括它有多容易，需要多少时间以及其他一些内容方面。
对于冲刺本身，开发人员应该估计完成各种任务需要多长时间。不过，确定故事的优先级并不是开发人员所做的一部分。需求收集会议也可以被视为制定项目章程，以便为整个项目制定一个时间表、目标和其他应在开始时说明的高级细节。
Could we call this, "Building the back log," as that is really what this is, to my mind? The idea is to get those top priority pieces and then work from there. I have seen a few different Agile processes and some worked better than others but the key is how well is the buy-in from those involved in the process.
I'd also agree that 1 month is too long for a sprint. 2 week sprints seem about right to my mind though I have seen slightly longer and shorter sprints that also work. Another question is how big is the team and projects that are being done as stuff that may take years may not be easily done. I say this as someone that survived a project that lasted over a year and many sprints and demos later finally finished the project successfully.
I'd likely consider the technical person being the one that has to keep an eye on the big picture and understand what may be reasonable to do and what is unreasonable to do,e.g. having the system read my mind to know what I want done before I wake up in the morning without my having to write out anything other than simply thinking it would be unreasonable. Don't forget that the stories will develop into more cards as the stories are just a high-level view of what the end result is, which usually doesn't cover how easy is it, how much time will it take and a few other aspects.
For the sprints themselves, developers should estimate how long it takes to do various tasks. Determining the priority of stories though isn't part of what the developers do though. The requirements gathering session could also be seen as building a project charter so that there is a timeframe for the project as a whole, objectives and other high-level details that should be stated at the beginning.