SCRUM and roadmaps
Hello
I am learning about scrum, so please excuse the basic questions. I had some queries I hoped people could help me with.
1. Let's say I am responsible for a software product. I completely understand that Agile is all about small, incrementally deliveries, but what if I my customers want to know what they'll be having in a year or so? Rather than have a GANTT chart saying X functionality will be available in 25 December 2018, is it better to say Q4? Or is that even against the concept of Scrum?
2. In my organisation, we have architects, developers, QA, operations. Would a cross functional team of all these people be best? How many is the best size - 7, 8 ?
3. Would a Product Owner be responsible for defining features in the next version of a product or developers themselves also involved?
Let's say I am responsible for a software product. I completely understand that Agile is all about small, incrementally deliveries, but what if I my customers want to know what they'll be having in a year or so?
For the product under consideration, would it really be possible to know that, so far in advance?
I think our customers would like to have an idea of 'what's coming'....this doesn't have to be tied to a specific date or sprint, but an idea that some sort of major feature they would like would be useful.
I think our customers would like to have an idea of 'what's coming'....this doesn't have to be tied to a specific date or sprint, but an idea that some sort of major feature they would like would be useful.
Is your Product Backlog properly prioritized?
If it is ordered and estimated, you have a rough idea of what the next things the Development Team(s) will be working on next. Depending on your environment, you may want to summarize the Product Backlog to customers to give them an idea of what new things will be coming up in the next few Sprints, but noting that it is subject to change if higher priority work comes in. You can also solicit feedback - if the next things aren't a priority for your customers, consider working with the stakeholders to reprioritize the work.
If you have a few Sprints completed, you may be able to roughly forecast how long to complete the Product Backlog in its current state, but that would be sensitive to changes in the Product Backlog. If the Product Backlog is large, you can at least determine what the next few Sprints are likely to look like. Again - both of these are dependent on the order not changing. However, it can be useful to start discussions with stakeholders. If there are expectations of certain work being done by a certain time and it doesn't look likely, the Scrum Team can work to reorganize the Product Backlog to support the needs of stakeholders.
I think our customers would like to have an idea of 'what's coming'....this doesn't have to be tied to a specific date or sprint, but an idea that some sort of major feature they would like would be useful.
What does the Scrum Guide say about the ordering of Product Backlog items and the level of clarity with which they might be expressed?
but what if I my customers want to know what they'll be having in a year or so?
I think the question is: What they would like have be in a year, considering business priority. Look... the responsability is all yours, and this is no good.
Do you have a roadmap by a year? Sit with your client and create releases to be delivered by quarter. So, plan with your team and show to your client.
With "release burndown" (I use Jira) You can see the evolution of your delivery and the estimate time to finished it.
I hope this may help you