Learn Software Development » Features

What is a MVP in terms of software product development ?

ashish — Wed, 07 Dec 2011 19:54:18 +0000

A lot of have people have not heard of the term called MVP. The full form of MVP is called Minimum Viable Product, and represents the set of features that is believed to be essential for the release of a product. The use of MVP is a strategy that decides the number of features that should be built into the product, just those set of features and no more. I will describe with an example as to how the MVP was used to drive the discussions about the list of features that should be part of the product version, given the compromises that need to be made with regard to the availability of resources, the time available, and the need to have features for the release.
Consider a case where a new version of the product needs to be released, and there is the familiar discussion about the feature list that needs to be approved for the product version. The product management team could come up with a large number of features, but that is just the starting point. The features need to be arranged in a prioritized set of features, associating them in terms of the most important, the ones that are somewhat less critical, and the ones that are good to have. This activity can take a fair amount of time, since the product management team has to balance the need for a feature in terms of meeting competitive pressures, in terms of getting good reviews (the initial set of reviews generated by professional reviewers in tech blogs and magazines), and being useful to customers, since that generates the overall positive buzz among customers in various tech / software related forums.
Once this priority has been set for the features, these features, especially the most important features, need to be set in terms of the MVP for the release. Getting such a list of features without which the product will not ship helps guide the discussion beyond this point. Thus, once the Product Management has set out a list of features that need to be done for the product to ship, and have convinced the stakeholders including management and the engineering team about this, then the rest of the discussion is about how to meet the MVP.
If the timeframe or the number of resources are not enough to get the feature set as defined in the MVP done, then the discussion moves towards debating the timeframe, as well as the number of resources available to the engineering team. In our current case, the number of features in the MVP were not being met, and the release was critical, hence the team got authorization for an increase in the number of engineers so that the feature set could be met. This was not possible until the must have feature set was defined, these forming the MVP.

What to do when priority of your requirements changes in the middle of the cycle ?

ashish — Thu, 13 Oct 2011 18:15:53 +0000

One of the questions that I saw recently coming up during a recent discussion was about what happens when you need to change your requirements during the middle of a Sprint cycle. This was a team that had set Sprint cycles of 30 days duration, and normally never had an issue with any modifications required during the Sprint cycle.
Typically, the Product Owner would define the list of features that are needed, puts them into a priority (and this would include infrastructural and design tasks that are stated by the team as well), and these are entered into the Product Backlog. Then, in the planning meetings, the team would work through the prioritized items, estimate the features and tasks that are likely for the current Sprint, and come to an agreement of which are the tasks that would make it for the current Sprint. Then it is a question of tracking the tasks through the Daily Scrum meetings and taking it through till the end of the current Sprint.
The twist in the tale comes if you need to modify the items in the Sprint. For example, suppose you have a list of items ready to proceed with and midway through the Sprint, the customer comes back and states that a very important feature has suddenly cropped up (needed for some business purposes), and hence it needs to be done for the Sprint. Now, this very question was asked by a team member when a situation arose where we needed to make such a change. Given that Scrum training can depend on the person giving the training, one of the people providing the training told the team that it is possible to modify the list of features during a Sprint cycle, as long as the Product Owner provides an updated prioritization of items. So, the list of features to be done in the Sprint could be different from what was initially decided.
However, this seemed a bit odd, since all the material that I had read till now seems to indicate that once a Sprint is started, you should not modify the list of features. It is also not easy, since any change has a significant impact on the ongoing Sprint, you have not given the team a chance to do an estimation of the changes. What is more likely (as I found from many articles on the subject) was that if the matter is so urgent, then the current Sprint should be curtailed as it is. A new Sprint should be setup where the new priority of features should be setup, estimated, and if necessary, the duration of the Sprint should be curtailed so that it matches the desired delivery date of the features. However, all this will have an impact on the productivity of the team, but if the importance of the required feature is so high, then this change will need to happen.

How to get the Design team integrated with the Product owner, including the scheduling (as a part of Scrum)

ashish — Tue, 05 Oct 2010 18:31:28 +0000

A part of the problem with using Scrum for product development is about when to get the Design team involved with the user stories. As a part of any development process, whether this be Scrum or Waterfall, or any other development process, it is necessary that the Design team works with the Product Owner (and then with engineering) on the actual design before the coding of the work starts. This process takes a certain amount of time, and if the engineering needs to provide a feedback mechanism about the different effort estimates of different designs (for example, the design team may propose a design that may require a lot more engineering work, while a simplified design may get the work done in a much shorter period), then the iterations taken by the design team may need a certain amount of time. Now, in a given Sprint, the effort estimation put by the team members typically starts with the code design and then the coding (and does not incorporate the time required for the user design).
What this translates into is the fact that the work needed for this work would need to start earlier than the current Sprint. So, the user design team along with the product owner would need to identify the features for a relevant Sprint earlier to the current Sprint (even though there is a potential that the features so selected may not make it to the future Sprints, if there is a re-prioritization, something that is very much possible in the Scrum based method). Then they need to spend the required period of time to break down the user story into user design concepts (and then being able to work with some folks from the engineering team to be able to take these user designs, see whether they are realistic or need tweaking in order to optimize the user design).
This is something that needs to be worked out by the various teams (the user design team, the Product Owner, and the engineering team) such that they are able to spend the required effort for this before the current Sprint. The engineering team needs to be able to identify people who will be on a constant interface with the user design team (they will also be able to tweak the architectural design for components of the project if they already know some of the future work).
Another complication comes in terms of trying to finalize the user design for the engineering team to work on. Typically, some amount of customer validation is necessary, but there needs to be effort to develop the required prototype for the customer validation of the feature. Further, all this needs to happen before the actual Sprint happens where the feature work needs to be done by the engineering team.

Learn about Scrum – Why does Scrum fail – Dealing with teams working across differnet geographies, optimization techniques

ashish — Sun, 11 Jul 2010 07:16:44 +0000

Scrum by itself is normally not a reason for failure of projects, it is more likely that there is a process implementation issue, or a logistics issue that has caused such failures. In a series of posts, I am trying to post some of incidents and examples that I have seen where the Scrum project has gone through significant challenges, or failed. So, in previous posts, I have the following examples: Sponsors not confident, Not able to empower the team, Problems in Daily Scrum, Team not ready to move to Scrum. In this post, I take another example where there is already a challenge present in terms of cross-geographical differences, and how the intense engagement required during some of the stages caused a problem. Now, if you were to truly dissect this problem, you could see the same problem when you are doing more of a Waterfall, except that in those cases, the deeper level of customer engagement is visible in the beginning of the cycle, and is not needed to that high level as you move ahead in the cycle.
So, what the team did was to take the current mixture of Waterfall and iterative development, with the current Product Manager in another geography that was located at a different timezone with a difference of around 13 hours (basically meaning night-day or day-night). Before the team moved to using Scrum, there were a lot of discussions about going in for the Scrum model, and how it would work for the cross geography connection. One advantage was that it was only the Product Owner who was in a different geography, and so there was less of the logistics of getting the Product Owner for discussions. And this was a Product Owner who had worked with the team in the past in the waterfall based method.
And yet, after the first month or so, inspite of the worries, things were proceeding more or less on the same way that they were in terms of interactions, and all. The problems started emerging after the first Sprint, a time when in the past, the Product Owner would have started reducing the interaction in real time, not needing meetings at common times (since reviews and other evaluations could be done through an offline mode, over email). However, when using Scrum, after the first Sprint, the team again needed intense interactions with the Product Owner for the fresh set of features, and there were issues about managing the logistics, and convincing the Product Owner. One could sense that the Product Owner was making an effort, and by the time of the third Sprint, things started getting more complicated. The Product Owner would push back on the number of discussions required, and also on trying to get a common meeting time. Just setting up those meetings would take more time and effort, and this started showing on the productivity of the team (since they could sense the discomfort of the Product Owner). By the end, the product was delivered, but things had started getting tense and strained.
What could be done ? For the next time, we had long discussions with the Product Owner on the type of interactions, made some compromises regarding the number of meetings per week, pushed the team to stay late once in a while so that 1 meeting could be held at a time convenient for the Product Owner, and that did make things better.

Learn about Scrum – Why does Scrum fail – The sponsors worried about the lack of a schedule of features in the overall project, this worry extending to the end of the project: Part 2

ashish — Mon, 05 Jul 2010 09:36:28 +0000

In the first post of the article, I wrote about how senior executives need to see the list of features before approving the product development (the list of features is reviewed in terms of competitor analysis, projections of the direction where the product should be heading towards, and also whether these are features that customers would be willing to pay money for).
Going by classical Scrum approach, the Product Owner generates a Product Backlog. However, the Product Backlog is not an approximation of the list of features that will make it in the product in the defined schedule, since there has been no breakup of the features into user stories, no estimation has happened, and so on (these steps happen in a very accelerated manner in the conventional process we used at the start of the project). So, either we still do such a process at the start of the Scrum cycle, which also means that we are going in for the breakdown of the features, going in for task estimation, and so on.
However, this sort of breaks down the core advantages of Scrum. Scrum allows you to respond fast to changing market needs, which means that features are prioritized and detailed at the Sprint planning level (with a Sprint typically being for a period of 2-4 weeks). If you confirm the list of features right at the beginning, then you are not able to modify the features through the cycle. Getting this past the executives was a bit complicated, with having to take through the broad directions of the product, as well as a list of features in the Product Backlog along with a list of priority.
Now, since this was the first time that the team was implementing Scrum, and this was an important product, the executives wanted a quick summary from the Sprint review meeting at the end of every Sprint. Now, the first few Sprints were where the team was learning about the Scrum process, and it took time for us to see progress in terms of getting the Scrum process working. However, in this case, since the executives were seeing progress from the first set of Sprint planning, and did not get a detailed schedule in terms of timing of implementation of features, they were focused on seeing whether the features that were planned for each Sprint were making it. This added a high level of pressure to the team managers, and also on the Scrum team. With the first few sets of Sprints not showing the desired progress, the review sessions with the executives got more and more uncomfortable; and it was getting harder and harder to justify the use of Scrum.
By the third month, we were behind the feature implementation (as seen in the Sprint Planning meetings), and given that we did not have a Product Feature Schedule in place, there was a feeling increasing in senior management that there was some foul-up happening. At this stage, there are 2 possible options – Either we slowly start to turnaround matters, and when we are confident that things are indeed improving, start projecting a much more positive attitude to senior management; or we face so much pressure that we are forced to go back to a Standard Waterfall process. Either case is a huge setback to the process of Scrum implementation.
What can improve matters in such cases:
- Get more success stories in terms of Scrum implementation in the organization, so that the senior management can have more confidence
- When projects are so critical, then the monitoring of the projects in terms of ensuring that Scrum processes are being followed needs to be much more careful
- Do more detailed interactions with senior management in terms of laying out what Scrum is, what are steps that need to be taken, what are some of the challenges, and so on.