Archive for the Release Planning Category

How to Prioritize Requirements YouTube Video

Posted in Agile, Business Value, Project Backlog, Release Planning with tags , , , on July 24, 2010 by vikramadhiman

I have written about how to prioritize before:

As Agile Product Managers, you are constantly prioritizing requirements to get higher value items out sooner. One approach I saw recently, seems very promising. Here is the video. Go ahead and watch it.

Basically, divide your requirements into four quadrants with Y-axis being Business Value and X-axis being Complexity. Hence, you would ideally do quadrant number 1 first and quadrant number 4 last. You can take a call between quadrant number 2 and quadrant number 3 – depending on what your current business strategy/ pull is. Simple. Do it over and over again and we will always provide higher value first.

Why does the Product Owner (PO) Disturb the Team?

Posted in Agile, Release Planning on September 2, 2009 by vikramadhiman

In Agile and Scrum talks or training, Product Owners (PO’s) or people playing the PO role in projects/ products, ask : Is it alright to ask the team how is it going during a sprint?

A good team would probably direct him/ her to the burndown chart or the Kanban inspired to-do lists. duly sorted in in-progress, to be picked up or done. The teams who do not maintain the burndown chart only have themselves to blame for the Product Owner or Product Manager, asking the obvious. Now, let us say the team maintain the burndown chart and the PO can see it, what if he/ she asks – Is this your best pace or Could you do better or I don’t think this is good enough? This is probably getting into a territory, where there is no yes or no – it is just something you have to analyze context wise. Let us analyze some of the reasons [assuming that the team is maintaining correct working pace and is not padding up or slacking]:

  1. Why the Product Owner could say such a thing? The Product Owner obviously does not trust the team.
  2. Why does the Product Owner not trust the team? Probably the PO has no clue what all we do.
  3. Why does the Product Owner not have this clue? Because he can’t see it.
  4. Why can’t he see it? Because we did not put it on the sprint backlog or to-do list.
  5. Why did we not put it? Because [A] We were lazy [B] All programmers and testers know what all it involves [C] It won’t make sense to business [D] It takes time

Other than [D] above, none of the above seems like compelling reasons for not listing all the tasks. Also, the consequences of not putting it because of [D] -> lack of trust in product management and development – is too big to account for extra minutes it takes to list all tasks and dependencies.

Hence, next time the PO has this urge to ask you>>please just ask yourself the 5 questions above and see if you can find a solution. If your PO asks you to change something/ do an extra thing/ tweak something>>then Scrum is pretty clear on how you should handle it :)

Ideal Iteration Length, Sprint Length, How Long should be a Sprint or Iteration

Posted in Agile, Release Planning, SCRUM with tags , , , , , , , , on January 11, 2009 by vikramadhiman

New teams struggling with Scrum or Agile adoption more than often struggle with their Sprint or Iteration Length. [Whether or not a Sprint or Iteration is a good thing or needed for Agility is a debatable topic in itself though]. Most of the teams pick up iterations or sprints month or even two months long. Then their idea of Iteration is moulded in Waterfall Phases [this is a Design Sprint, this is a Coding Sprint, this is a QA sprint and this is a Release Sprint] – this is for another day. When deciding on the length of a sprint or iteration, many factors need to be considered:

  • Administrative Overhead : Each iteration needs a planning meeting/ game to kick start the iteration. Each iteration would also need a closing/ review meeting. And there will also be a retrospective at the end of iteration. Although one can say that the size of these meetings [minutes consumed] would depend on the length of sprint, so as long as these meetings comprise say just 10% [you can come up with your number] of overall time available for a sprint/ iteration, it should be fine. I personally think this reasoning is fine. If meetings are taking longer, then there are generally Process Smells – Product Owners who have not done their homework correctly or have not had the chance to review the deliverables properly.
  • Feedback/ Flexibility : Shorter the duration of the sprint/ iteration, earlier the feedback and correction and more flexibility, longer the duration of the sprint/ iteration, longer the correction – more chances of canceling the sprint and more chances of things being obsolete [competitive advantage erosion].
  • How good is the marketing team : If the marketing team is good [Product Owner is good], then he/ she will break the stories or tasks small enough to keep sprint/ iteration length small. He/ she would know the worth and priority for each story or task and help the team pick up most important stuff – minimizing stuff thats not needed – helping the team become Agile.
  • How Fast can the team move : This is generally the most important factor in deciding a sprint length. Assuming the team has a good marketing leadership, one reason the team does not commit to a smaller iteration is lack of confidence in themselves. If they had confidence in themselves [they were doing refactoring, TDD, shared code or just were good group of people together].
There was a certain slant for a smaller iteration length in the post. This is because:
  • Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.
  • Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.
  • Shorter sprints or iterations force continuous evaluation regularly and quickly.
  • Shorter sprints or iterations also allows the team to establish
    an empirical velocity very quickly.
Some people and trainers say that when teams are new to Agile/ Scrum, they could start with 2 week sprint. I generally advise against this. I would rather have them do 1 week sprints with lesser stories – allows them to learn quicker and faster. However, important point to note is that each team is unique and each product is unique as well – hence, there might be cases for 2 weeks as well as 2 months sprints. I haven’t come across any so far though.

Prioritze tasks for web and software development : Issues

Posted in Agile, Business Value, Release Planning with tags , , on September 15, 2008 by vikramadhiman

Any product manager or business analyst has always been stuck with how to prioritize stuff and development work.

The basic approach that people generally use to prioritize development tasks:

  • Write down all the pending development items, as and when you think of them at a common place.
  • Assign them a priority of high, medium or low [or something fancier] and pick up the high priority items first.
  • Keep compiling the list of most high priority items as you go. There are many problems in this kind of prioritization.

The major problem is that any decent sized project/ product would have a lot of development items as open. And most of these items are always high priority or medium priority but not low priority. Hence, you have to do a nested priority tango [where you prioritize between high priority items further with something like Very High Priority, Super High Priority etc], till you are left with the items you can pick up for the next release.

Although very simple to look at, as the data grows, this method becomes a complete mess for you to manage your priorities and also takes a lot of time for managing the priorities. In addition, this gives some items with low priority a wrong interpretation – these are not important, and even worse, confuses the high priority items as the most important. Another major problem that development teams face is classifying the items as bugs, defects, new features, revision of old features etc and sort of prioritizing within this.

Hence, the main problems in the main approach is:

  • As the data grows, managing the priorities becomes an issue
  • Making an item/ task as not important, low priority, can wait, not urgent, good to have – makes people take those tasks/ items lightly
  • Prioritizing within the items/ tasks – bugs, defects, new features, revision of old features

A quick review of Internet threw up some variations of this approach:

  • OrganizeIt.com suggests that you should prioritize the stuff between must do, should do and would like to do. The only problem with this approach is that different arguments can convert a would like to do into a must do.
  • OpenBravo has a delicious looking approach to development process management and takes a linear time bound approach for each task. I have not used OpenBravo as yet but probably this would probably work well in some circumstances as long as you make sure you enter the right data.
  • A common approach in Scrum Projects is to have teams gather around for a Sprint Planning Meeting and arrive at a consensus on what they would need to develop in the next sprint. Everything else waits. This is a good approach. However, the work involved in estimation of the items/ tasks and discussions can sometimes extend. This is not a problem with the approach but signifies something else [communication gap between the teams and product owner]. Unfortunately, not many people would see it like that [I will cover this topic in more detail later].
  • Another very effective approach [again borrowed from Scrum/ Mike Cohn's work] is to first draft coarse grained requirements and refine the ones that are immediate priority. This takes care of not having too many requirements/ items while still having enough detail for meaningful priority for the tasks / items at hand.

Now that, we have discussed in brief what we probably already know, I will try and analyze why these problems appear.

  • No single product owner
  • Too long a time before priorities can be changed
  • Wasted effort on not so hear horizon tasks [which might never get done, or are changed when those are picked up]

However, the biggest issue is that prioritizing the above way gives you a false sense of security that you understand how the future would unfold. You lock yourself up in decisions [based on a prediction of future, and a growth path/ evolution of product or features]. This is the exact mindset and belief which Agile [or "a"gile ???] seems to correct. The product management teams and development teams, both need to be open to all possibilities. Unless the mindset which develops the products is open, we fight keeping the natural progress of the product [based on customer requests and inputs] at bay.

Now that we have seen the issues in prioritizing using conventional techniques, lets try and see an alternative approach to prioritization.

    Time available in a sprint

    Posted in Release Planning, SCRUM with tags , , on December 7, 2007 by vikramadhiman

    One of the themes which I get asked most often is, how to calculate how much time is available in a given sprint and to know if someone is overcommitted or undercommitted during a sprint. And its not Scrum Masters, but teams asking this question.

    Well lets say the team comprises of four members – Anand, Lee, Sam and Pamela. In addition, there are two part time members – Rose and Kate. We assume there is a two week sprint. A 4 hour sprint planning and 4 hour sprint review/ retrospective means one day of the two week sprint goes in ceremonies. The first step is to ensure every one is available for these ceremonies. Once they are there, you can write down each of the coming working days and check for half day leaves/ full day leaves or other engagements for everyone. You can then note down effective hours everyone has available and do the total. Doing this every sprint can give a “very rough” mapping between hours available and story points burned. Why this approach works is because we are not mapping hours spent and story points burned. As hours available and story points burned are suitably high level abstractions of estimates and planning – this gives “rough insight” for a team to plan.

    Another variant of this approach is to try checking how many quarter days each member has available. You don’t know how many hours in quarter days has one available, just how many quarter days are there [in all there are 4 quater days a day]. You can then map the quarter days with story points burned. Similarly, half day approach can be tried.

    Both the above approaches are supposed to be used only if team members would want to use them as a rough insight into how much work to plan. This would be probably useful also if the team adds or removes members often, and some sort of rough guidance for the team on time available and story points to be picked up is helpful.

    Potentially shippable code – continued

    Posted in Agile, Business Value, Release Planning, SCRUM with tags , , , on October 15, 2007 by vikramadhiman

    In the last post, we discussed how not to meet potentially shippable code. However, we never really addressed the question as to why is the potentially shippable code that important anyways. It is often argued that the relentless focus on getting to potentially shippable code, is what sets Agile apart from other incremental and iterative processes. This is partly correct. Partly, because there are certain values which Agile stands for and if those are not used for the development, you are not really doing Agile.

    Potentially shippable code as discussed in the previous post is always just one sprint away from shipping. Why this is important is because:

    1. It keeps the focus on priorities for the customer. She knows that all she needs to do to get the product to the market is announce a pre-release sprint and she will get it. After the first few sprints are done, the incentive to organize the product backlog to develop the product in a manner where it could be released any time focuses product owner to provide value to the project by prioritizing the items based on importance, ROI and risk.
    2. The team can think of an iterative and incremental mode of development – with preference to get to overall product structure as soon as possible. In fact is the product backlog has been priorotized well enough, enough value would be got early in the development rather than later, and actually the value added in future sprints could be much less. This provides tremendous ROI for the product owner and again – focuses them on considering priorities on an incremental and iterative level as well.
    3. It focuses the team to install engineering practices which will help them get to really done. Some of XP practices like refactoring, unit testing and code sharing help the teams really perform extremely as well as at a sustained pace.
    4. Overall, it provides an opportunity to get feedback and adjustment.

    One of the tests of whether teams are doing Scrum in Nokia, include reference to “do you provide potentially shippable code at the end of the sprint?”. I have found focus on potentially shippable code really good way to help provide focus for all concerned on product success.

    7 Ways to Fail to Deliver Potentially Shippable Code at end of Sprint

    Posted in Agile, Business Value, Release Planning, SCRUM with tags , , on September 30, 2007 by vikramadhiman

    Before we address the question of how to *not* deliver “potentially shippable code” at the end of the sprint, it would be interesting to define what is “potentially shippable code“. I don’t know where I read this definition – “potentially shippable code” is only a sprint away from release. Whether or not the code is actually shipped or not would of course depend on does it make *business sense* to ship the code right now or after doing another sprint or two. As you are developing based on prioritized set of features and delivering “potentially shippable code”, you are never far from release. However, you are not reading this blog to find out how to produce “potentially shippable code” at the end of each sprint. Rather, we will discuss how you can through lot of “painful, slow and planned” effort not deliver “potentially shippable code“.

    1. Step 1: Do not define DoneLet everyone define what “done” means without communicating on it
      Customer expects to see a tip top UI that functions perfect
      Team is busy building backend and code behind files with lousy UI
      Management thinks the team is building the code that can be supported
    2. Step 2: Departmentalize and Compartmentalize work to be doneYou have to make sure that work is divided in various departments who can blame each other at the end for a job not done. Here are some steps you can take to ensure that:
      Take Quality out and place them in another department with procedural barriers to collaboration among the two teams
      Do the exact thing with UI designers
      If you can do it, divide the work along horizontal layers like database design, business logic design, interface coding etc – the more you can, the better it is
      Do not forget to add ceremony and processes on how different departments should communicate with each other
      You don’t need to include technical writers, UI review surveyors and other support functions in each sprint – have them learn about your months long project in 10 days and churn up some documentation and reviews
      Doing it last minute and hurriedly without a review is the most important thing here
    3. Step 3: Insist on elaborate upfront design documents and architecture designs – Ensure that team worries more about “how they will achieve goals” rather than goals themselves. You can do that pretty easily. Think of the latest modeling techniques and use it to model. Other steps you can try:
      Define all the tasks and their dependencies upfront
      Think about the design rather than what the design should help achieve
      It will help if you can spend a lot of time defining the architecture
      Make developers just Architecture to Code converting units
    4. Step 4: Write crappiest possible code that no one would dare to touch in future – This one take special art, after all by the time anyone will touch the code you wrote, you would be in your third job already. Still, you must plan out in great detail processes which help you write the crappiest code possible:
      To ship potentially shippable code, the team not only needs to work on prioritized features, but also maintain a good velocity – so do everything to ruin it
      Write crappiest possible code [no comments, no standards, no reviews]
      Drive developers to guard their code like treasure
      Make developers horrified of others code [success: this was not my code, why should I fix these bugs]
      Make sure your code breaks the build when you check that in and try doing that the last thing in the day
      Make sure your code has low cohesion and high coupling so that any change in any part of code goes and affects totally unrelated part of the code
    5. Step 5: Code first and test later and if possible leave testing for another sprint – Who wants to do any testing, thats the lowest possible denomination of tasks in a project. Testing is not as sexy as design, analysis, coding and processes. Also, what value does testing provide to the organization or project. Hence, you should make sure your team treats testing as just a necessary evil that has to be done because processes say so. You should try the following to keep this evil as away and as low as possible:
      Testing should be done at the end of the sprint or if possible in the next sprint
      Make sure you don’t write any test cases so that testers have to go through the code and functionality manually each time they do the testing
      Ask testers to test even the smallest change you make to any functionality
      Make responsibility of testing only the QC departments – you are here only to code
    6. Step 6: Change and chop team/ developers – Who wants stability? Management wants flexibility and pre-sales team wants to show developers for new projects. Hence, take as many developers as possible and get new work or shouting customers out of the way. The silent and steady projects mean that they are just too easy to manage and can do with resource snatching. Hence, its important that your developers are constantly changed and chopped between projects between sprints if you want to fail. Additionally, make sure testers, designers etc are changed as well. If you can manage to change SCRUM Masters and Product Owners between the sprint as well, nothing like it
    7. Step 7: Make the same mistakes over and over again - This is important. It’s going to be no use if you make the carefully planned mistakes outlined above and then go about fixing them. Make sure you only discuss what’s going to be served in next sprint retrospective and blame every one else but yourself in Sprint Retrospectives. Do not focus on above issues.

    If after trying all of the above, you can still produce “potentially shippable code” at the end of each sprint, then please call me. We will create a new software development methodology :-)

    Follow

    Get every new post delivered to your Inbox.