Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
presented by tanvir afzal
a little go through <ul><li>our company is following scrum, so we do standup meeting on daily basis and we report to scrum...
agenda <ul><li>future plan </li></ul><ul><li>time limit </li></ul><ul><li>product complexity </li></ul><ul><li>lot of feat...
future plan <ul><ul><li>what we are going to release? </li></ul></ul><ul><ul><li>how we will proceed? </li></ul></ul><ul><...
time limit <ul><li>If we have a tight schedule and lot of tasks are there that may not be possible to achieve then most of...
product complexity <ul><li>our products are service oriented. </li></ul><ul><li>our products depends on our services like ...
lot of features? <ul><li>“ quality or quantity” </li></ul><ul><li>If there is 10 features then we can take 2 or 3 feature ...
unclear requirement /  without use case diagram <ul><li>most of our requirements are on sprint planning and we get design ...
underestimated tasks <ul><li>sometime we think this task is so simple and we can develop it quickly but it is much more co...
lot of existing bugs <ul><li>If we have lot of existing bugs and when testing the product with those bugs, it blocks our w...
new requirements <ul><li>Any new requirements? </li></ul><ul><ul><li>We can keep all our new requirement into trac so late...
release without evaluating existing defects <ul><li>sudden release is kind of suicide. </li></ul><ul><li>when we are relea...
ending <ul><li>The more we face problem, the more we can fix and more we can fix will give us more quality and more smilin...
Upcoming SlideShare
Loading in …5
×

what's blocking our way

489 views

Published on

just my experience after releasing a software and after that release i started to think how we can improve ourself more. thats what i share on this slide

Published in: Technology
  • Be the first to comment

  • Be the first to like this

what's blocking our way

  1. 1. presented by tanvir afzal
  2. 2. a little go through <ul><li>our company is following scrum, so we do standup meeting on daily basis and we report to scrum master. </li></ul><ul><li>We deliver something on each of the sprint. </li></ul>
  3. 3. agenda <ul><li>future plan </li></ul><ul><li>time limit </li></ul><ul><li>product complexity </li></ul><ul><li>lot of features? </li></ul><ul><li>unclear requirement / without use case diagram </li></ul><ul><li>underestimated tasks </li></ul><ul><li>lot of existing bugs </li></ul><ul><li>new requirements or new ideas </li></ul><ul><li>release without evaluating existing defects </li></ul>
  4. 4. future plan <ul><ul><li>what we are going to release? </li></ul></ul><ul><ul><li>how we will proceed? </li></ul></ul><ul><ul><li>is it logically possible? </li></ul></ul><ul><ul><li>how many bugs can be found </li></ul></ul><ul><ul><li>dependency of the future plan </li></ul></ul>
  5. 5. time limit <ul><li>If we have a tight schedule and lot of tasks are there that may not be possible to achieve then most of the time we focus to creating new things rather then fixing existing features. </li></ul><ul><li>if deadline is near we push our self to achieve the goal not the quality </li></ul><ul><li>we didn’t organize our self to complete a task. </li></ul><ul><li>suddenly some major tasks came out and we took over that tasks. </li></ul>
  6. 6. product complexity <ul><li>our products are service oriented. </li></ul><ul><li>our products depends on our services like cpwebservice, cpsmsservice and widgets. </li></ul><ul><li>lot of scenarios to test and lot of possibility to find out bugs. </li></ul><ul><li>resources are limited and complex level is higher. </li></ul>
  7. 7. lot of features? <ul><li>“ quality or quantity” </li></ul><ul><li>If there is 10 features then we can take 2 or 3 feature in a sprint and then develop and fix bugs then we go for another one. It is slow but more effective and more reliable. </li></ul>
  8. 8. unclear requirement / without use case diagram <ul><li>most of our requirements are on sprint planning and we get design for it, so when we discuss there is a possibility to forget the requirement. </li></ul><ul><li>we can use use case diagram. </li></ul>
  9. 9. underestimated tasks <ul><li>sometime we think this task is so simple and we can develop it quickly but it is much more complex then it looks like and that easy tasks can be the cause of new bugs. </li></ul>
  10. 10. lot of existing bugs <ul><li>If we have lot of existing bugs and when testing the product with those bugs, it blocks our way to test. because when we found a bug we need to think: </li></ul><ul><ul><li>is it reported ? </li></ul></ul><ul><ul><li>why it came up? </li></ul></ul><ul><ul><li>is there any related bugs or other module is affected with it? </li></ul></ul><ul><li>yeeeaahh I found a bug ! ! ! That’s really awesome now please put it on trac. our test team will have a look at it. </li></ul>
  11. 11. new requirements <ul><li>Any new requirements? </li></ul><ul><ul><li>We can keep all our new requirement into trac so later we all can have a look at it. </li></ul></ul><ul><li>Any kind of sudden requirement when we are in sprint can easily pull us out of trac. so we need to find a solution about it. </li></ul>
  12. 12. release without evaluating existing defects <ul><li>sudden release is kind of suicide. </li></ul><ul><li>when we are releasing any product. Its our long term effort and our precious time that we have given. </li></ul><ul><li>so before we will release we can have a look at bug lists then we can decide we will release it or not. </li></ul><ul><li>If the quality is not achieved then we can decide what will be the new deadline and why we didn’t reach our goal ? </li></ul>
  13. 13. ending <ul><li>The more we face problem, the more we can fix and more we can fix will give us more quality and more smiling face  </li></ul>thanks

×