presented by tanvir afzal
a little go through our company is following scrum, so we do standup meeting on daily basis and we report to scrum master.  We deliver something on each of the sprint.
agenda future plan time limit product complexity lot of features? unclear requirement / without use case diagram underestimated tasks lot of existing bugs new requirements or new ideas release without evaluating existing defects
future plan what we are going to release? how we will proceed? is it logically possible? how many bugs can be found dependency of the future plan
time limit 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. if deadline is near we push our self to achieve the goal not the quality we didn’t organize  our self to complete a task. suddenly some major tasks came out and we took over that tasks.
product complexity our products are service oriented. our products depends on our services like cpwebservice, cpsmsservice and widgets. lot of scenarios to test and lot of possibility to find out bugs. resources  are limited and complex level is higher.
lot of features? “ quality or quantity” 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.
unclear requirement /  without use case diagram 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. we can use use case diagram.
underestimated tasks 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.
lot of existing bugs 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: is it reported ? why it came up? is there any related bugs or other module is affected with it? yeeeaahh I found a bug ! ! ! That’s really awesome now please put it on trac. our test team will have a look at it.
new requirements Any new requirements? We can keep all our new requirement into trac so later we all can have a look at it. 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.
release without evaluating existing defects sudden release is kind of suicide. when we are releasing any product. Its our long term effort and our precious time that we have given.  so before we will release we can have a look at bug lists then we can decide we will release it or not. If the quality is not achieved then we can decide what will be the new deadline and why we didn’t reach our goal ?
ending The more we face problem, the more we can fix and more we can fix will give us more quality and more smiling face   thanks

what's blocking our way

  • 1.
  • 2.
    a little gothrough our company is following scrum, so we do standup meeting on daily basis and we report to scrum master. We deliver something on each of the sprint.
  • 3.
    agenda future plantime limit product complexity lot of features? unclear requirement / without use case diagram underestimated tasks lot of existing bugs new requirements or new ideas release without evaluating existing defects
  • 4.
    future plan whatwe are going to release? how we will proceed? is it logically possible? how many bugs can be found dependency of the future plan
  • 5.
    time limit Ifwe 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. if deadline is near we push our self to achieve the goal not the quality we didn’t organize our self to complete a task. suddenly some major tasks came out and we took over that tasks.
  • 6.
    product complexity ourproducts are service oriented. our products depends on our services like cpwebservice, cpsmsservice and widgets. lot of scenarios to test and lot of possibility to find out bugs. resources are limited and complex level is higher.
  • 7.
    lot of features?“ quality or quantity” 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.
  • 8.
    unclear requirement / without use case diagram 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. we can use use case diagram.
  • 9.
    underestimated tasks sometimewe 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.
  • 10.
    lot of existingbugs 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: is it reported ? why it came up? is there any related bugs or other module is affected with it? yeeeaahh I found a bug ! ! ! That’s really awesome now please put it on trac. our test team will have a look at it.
  • 11.
    new requirements Anynew requirements? We can keep all our new requirement into trac so later we all can have a look at it. 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.
  • 12.
    release without evaluatingexisting defects sudden release is kind of suicide. when we are releasing any product. Its our long term effort and our precious time that we have given. so before we will release we can have a look at bug lists then we can decide we will release it or not. If the quality is not achieved then we can decide what will be the new deadline and why we didn’t reach our goal ?
  • 13.
    ending The morewe face problem, the more we can fix and more we can fix will give us more quality and more smiling face  thanks